logilogi-list Mailing List for LogiLogi - Software Libre for the Web (Page 9)

> Ok, it's good that it's already not so late and I ended playing
> arround with UI colors, layout etc, but some advance still.
>
> See the two files UI_proposal_D_softblues.svg and UI_proposal_D_softcolors.svg

First of all I like the colorscheme of softblues; that's surely an
improvement over all previous color-schemes...

Also the addition of the little person-pics or even the thinker for
those without gravatar is a nice idea...

Secondly I'm not overly happy with how things went this evening and
tonight, and especially not about you then taking into consideration 
the user-impression test and saying the Mix is ok, but then tonight 
taking the design many versions back especially on many good bits of
the header and the text-clouds without, regard to the user's views 
about them (& not merging them in yet)... 

Still, I do see what you said on using the D-file for the font-sizes
and because of some other tweaks, as a working file, and merging the
improvements into it, so here per your request I merged some into
UI_proposal_D_softblues.svg and also added one new improvement, which
I hope should finally mean a good place for the create logi button;
central, and still not in places where it adds overcomplexity to the
design...

I will go over the improvements one by one:

- First of all the create new logi button. I added it to the right of
the secondary tabs (which are now proper tabs again instead of links). 
So we now have Search, Browse, View tabs and then the New-button. Hard 
to miss, and in a spot that would make sense for an user to look 
into...

- This also allows the bottom of the query-bar (the design-one, instead 
of the mere bar) to be simpler, so it just has the peergroup-selection,
and is easier to implement (one less image needed). Also putting the
peergroup selection there is meaningfull as it has consequences for
the rest of the page, just like the query, and also will be there in
all logis views, so it's more consistent to have it there than tucked
into another box below it.

The query bar also has the advantage that we have no weird situations
when pplz with higher resolutions visit the site. The title bar can
stretch to the side, while the query bar and the tabs stay put, nicely
separated from the background & sides...

- Also I changed the curve of the connecting bit between the title bar
and the query-bar a bit, so it fits nicely around the create logi 
button and is also more simmilar to the other curves on the page. 

- The connecting bit is there because it provides a nice background
for the Create, View, Browse or Find logis description, because it
makes things look more connected (also prevents a clash between the
query bar and the title-bar), and because it can be there without
causing illogical top-tabs or something (still don't think that even
if it did users would care, at least those I asked on the Mix layout
did not, but schwa if you want this) as there are likely going to be
sub-tabs for, besides logis, at least changes (logis, users, etc),
groups (user-groups and peer-groups) and help likely too (as that
links to help-logis). Then for the mainpage we can make something
beautifull...

- The tags in the query bar are good in size, but giving them the same
color as the menu-bodies seemed a bit problematic to me for if we want
to show them in clouds and things like that.

- The little help-icons are I think a good thing for usabillity, and I
would suggest having them for unregistered users on by default, and at 
least for contenders, remarks, comments, and incoming links... PPlz
liked them.

- The box around the logi also needed to stand out a bit, I think
and while not sure about the color, I assumed it was an unused bit of
the color-scheme, that seems reasonable, but might also be changed...
I also changed the color as it could be a bit confusing that the
selected 'View' had the same color as the buttons, leaving the user 
maybe wondering whether to press it. With the different encirceling 
color we don't have this problem and can color the not-selected edit 
and insert ones like buttons.

- And these tabs on the logi are also, I think better put on the
inside and to the right as then they give the title a bit more
headroom and are less in the way...

- I suggest for the background-color of the selected contending logi
we use white again, as from the border-color and the pointy thing
between it and the logi it is already clear enough what their
relationship is, and while it might be nice and logical to have it
colored like a menu-title, I think it's just not beautiful (at least
2 users specifically mentioned it as being repulsive in the 2designs
version), and also brings hoop-jumping with regard to the background-
color of the ratings (the white blob around them)...

- As already hinted at, the informative, and social teasing text-
balloons are back for unregistered users. This because users simply
were positive about them, and because they also do explaining and
motivation. The greyish informative texts like the one that was there
for remarks are no match for this. I suggest differentiating them from
the link-popovers for clarity (and the link-popovers would take up
more space if embedded cleanly into the design), and implementing them 
as images for simplicity... (later on we could even generate them with
LLCorners with some small modifications to that).

Also I added the Welcome back in front of the user-name in the title-
bar, as it's good to be friendly and polite, and not everything has to
look as formal and stiff as a banking-application.

- A small fix was applied to the incoming links, John Searle was too
much to the left...

- The border-colors of the recent votes and remarks were made light-
blue so they fit in better and stand out less...

These are the improvements. I hope you see them as improvements too,
Bruno, but where you don't I think we need to discuss them (instead of
us just 'yes', 'no', 'yes', 'no'-ing), or maybe even have a small
user-survey again, as most of these things are too important to the
design to let them pass by, or be decided by ego's or other forces 
than quality...

(Some fonts might be weird because of the windows-linux divide (I
changed none but added info-icons which might be placed wrongly for
windows), but I also uploaded a png so you at least can see how it's
without those... here:
http://www.logilogi.org/pub/UI_proposal_D_softblues.png)

In all I do think it was good to have the font-coloring and sizes of
the D-file as in the other design they still were not styled & often
too small and less beautifull... so good work on that :)

> The blues scheme is the one I like the most, but the colors are a
> matter of personal taste, and the green looks good, and a red, black,
> violet, would do too. We could have it as an option, not hard to do,
> and a high contrast schema would be good for some people.

Indeed, we agree on this, the blues is best and I think also most
fitting with many color-preferences...

(& yup we can have color-styles-selection by users & a setting later on)

> This time I took in count font sizes and small details, so I suggest
> start using this file as base (I'm talking about the blues one). If
> you Wybo want to make modifications, go ahead, or do them in other

I did the transfer for you...

> file and I'll incorporate them, either if you want to bring back you
> proposals or whatever, just add them here so we keep the fonts, tabs,
> etc. Also if you want another color scheme, I'll incorporate to this
> layout. We can then move this file as the base UI svg and maybe erase
> most of the files from the svn if you think so.

We can leave the files for archival purposes, to see where we've
been...

> I'll move now to the html work, will report on this later.

Good that we're now moving into html, and it looks like a good
skeleton & start...

If you encounter any problems with the query-bar or the header-bar (&
connecting bit) or think them too hard to do, I can help out some time
on implementing those as I already have an idea of how to do them with
images.

greetings,

Wybo

PS: The dentist-visit went well this morning, no problems left. I
might make a start updating the controllers for the xapian
link-resolving this afternoon, and this evening + night I will be at
the student- association, for a party since weeks...

> -- 
> Bruno

Also, about the logi toolbar, I moved it outside of the logi box as I
think it was kind of fighting for a place with the title and I didn't
like it, although I liked how it looked, it was not nice with the
title, too intrusive...

On Sun, Sep 7, 2008 at 10:41 PM, Bruno <bs...@gm...> wrote:
> Ok, it's good that it's already not so late and I ended playing
> arround with UI colors, layout etc, but some advance still.
>
> See the two files UI_proposal_D_softblues.svg and UI_proposal_D_softcolors.svg
>
> They are a mix of both proposals too, Wybos and mines.
>
> Also note that I made a new approach to the navbar that has some
> advantages. It uses up space better, it's easier to do in html and
> will use less resources (not very important but still)... It's a more
> KISS.
>
> The blues scheme is the one I like the most, but the colors are a
> matter of personal taste, and the green looks good, and a red, black,
> violet, would do too. We could have it as an option, not hard to do,
> and a high contrast schema would be good for some people.
>
> This time I took in count font sizes and small details, so I suggest
> start using this file as base (I'm talking about the blues one). If
> you Wybo want to make modifications, go ahead, or do them in other
> file and I'll incorporate them, either if you want to bring back you
> proposals or whatever, just add them here so we keep the fonts, tabs,
> etc. Also if you want another color scheme, I'll incorporate to this
> layout. We can then move this file as the base UI svg and maybe erase
> most of the files from the svn if you think so.
>
> I'll move now to the html work, will report on this later.
>
> --
> Bruno
>



-- 
Bruno

Ok, it's good that it's already not so late and I ended playing
arround with UI colors, layout etc, but some advance still.

See the two files UI_proposal_D_softblues.svg and UI_proposal_D_softcolors.svg

They are a mix of both proposals too, Wybos and mines.

Also note that I made a new approach to the navbar that has some
advantages. It uses up space better, it's easier to do in html and
will use less resources (not very important but still)... It's a more
KISS.

The blues scheme is the one I like the most, but the colors are a
matter of personal taste, and the green looks good, and a red, black,
violet, would do too. We could have it as an option, not hard to do,
and a high contrast schema would be good for some people.

This time I took in count font sizes and small details, so I suggest
start using this file as base (I'm talking about the blues one). If
you Wybo want to make modifications, go ahead, or do them in other
file and I'll incorporate them, either if you want to bring back you
proposals or whatever, just add them here so we keep the fonts, tabs,
etc. Also if you want another color scheme, I'll incorporate to this
layout. We can then move this file as the base UI svg and maybe erase
most of the files from the svn if you think so.

I'll move now to the html work, will report on this later.

-- 
Bruno

The outcome of the impression-test is:

http://www.logilogi.org/pub/2designs.png

5 for the left one (C), and 4 for the right one (D)...

Which is about even...

Some remarks and reasons:

sbp of Esp:
  Left is better, softer, more varied tones
Charles:
  Take header of left one and add it to right one, and have text-
  clouds on mouse-over or for unregistered users (see below).
My mom:
  The colors of the left one are calmer, and one can work with that
  one longer... The little clouds with explanations are handy this
  way, when on mouse over one has to get lucky to move the mouse
  somewhere, only then to see why that's usefull.
Mensan_A
  I like bigger areas in light colors, so the left design. Permanent
  text-clouds are irritating, they should be mouse over or
  unregistered...
Mensan_B
  The green one, it jumps out, the blue one is too faded
Mensan_C
  I go for the left one as I just don't like green
Mensan_D
  The green one seems calmer than the left one
Mensan_E
  I like the left one much more
Mensan_F
  I vote for the green one, looks much bolder, but off course it must
  match with the public and the wanted image

The remarks explain a bit more. Some people like some colors some
don't, but in general the colors of the right one are regarded better
than those of the left one, while the header and text-clouds of the
left one are seen as a bit better...

To conclude things (hopefully) I just committed a proposal that mixes
the best from both in 2 color-styles. You can find them as:

UI_proposal_Mix_Green.svg
UI_proposal_Mix_Blue.svg 

(only the logi-view has yet been colored fully...)

I would say we go for the green one, which uses the colors of design
D, and the contenders on the menu-background, but the (a bit
simplified, without borders) top and text-clouds (for unregistered
users) of C...

Which is; I hope more or less objectively; the best of both worlds :)
(and surely a lot better than what we started out with)

Also I hope you, Bruno, agree with this procedure of a little 
democratic user-test, as we make it for people like them, in the 
end... 

greetings,

Wybo

Some sources:

IRC-conversation with Charles:

(12:25:25 PM) Charles`: well, aside from the colours, they're pretty
much the same..
(12:25:40 PM) Charles`: maybe the right (green) one looks a bit more
pro
(12:25:45 PM) wybo: lol, the top-bars are quite diff
(12:26:02 PM) wybo: and the contenders in or out a box
(12:26:50 PM) wybo: and the speech-clouds yes / no
(12:27:26 PM) wybo: I mean we've come a long way already, that's true,
but there's still these diffs that make some diff...
(12:27:45 PM) Charles`: yeah.. I would go for the right one
(12:28:31 PM) wybo: on all aspects ?
(12:28:50 PM) Charles`: there's one thing I don't get..
(12:29:12 PM) Charles`: why show the current logi in the contenders
list?
(12:29:37 PM) wybo: The idea behind that was clarity...
(12:29:56 PM) wybo: So the user sees the connection with the current
logi
(12:30:49 PM) Charles`: fair enough
(12:31:35 PM) Charles`: the left header is a bit better though, with
the peergroup and add logi buttons part of the header
(12:31:51 PM) Charles`: so maybe transfer that idea to the right, and
it's perfect :)
(12:33:31 PM) wybo: 'k, I'd be happy with that, will post this
conversation to the list as output of the little user
impression-survey I'm doing now :)
(12:33:48 PM) wybo: and what about the little texts clouds with Can
you do better ?
(12:34:41 PM) Charles`: maybe for mouse-over, maybe for unregisterd
users.. but I wouldn't show them always
(12:35:01 PM) wybo: I thought for unregistered users
(12:35:22 PM) Charles`: yeah
(12:38:07 PM) wybo: ty for ur comments, really usefull for us now :)

IRC-conversation with sbp of Esp:

(12:01:20 PM) wybo: yo pplz, I have a design issue at hand, which
design do you pplz think looks better ? also in parts ? Should be
usable by little xpd users
(12:01:32 PM) wybo: http://www.logilogi.org/pub/2designs.png
(12:09:16 PM) sbp: left
(12:11:03 PM) wybo: 'k ty for ur opinion, any reasons / aspects why ?
(12:11:59 PM) wybo: (so we might come to a mix)
(12:52:21 PM) sbp: softer tones are less distracting, and I think the
variety works very well together
(12:52:33 PM) sbp: it's less dreary too

> I'm going to be short as I had a big problem and it got too late.
> While on windoze my computer went without battery because of the
> outage my computer whent standby, and when waken up I started linux,
> and there I worked for like 5 hours on the UI. Then when going to
> sleep I wanted to do some stuff on windoze so booted and it resumed my
> session, and that erased all my modified files, so no more work there
> :( just share this with you becouse there where 3 more proposals but I
> just had to redo only the one that I liked the most. The others where
> not very good, but there where part of the process...

Auch, that's some bad MS-luck... Sucks to lose hours work.

> My proposal D_green is a greens pallete with brown and white. The idea
> is that this could be done with any color. I used the same 3 or 4
> colors in all instances so it's very easy to change them in all items
> at same time, just search (ctrl + f) for example fill:#a7c520 and it
> selects all objects with that fill.

'k Handy.

> Also you'll see that I took back things to what I wanted them to be
> like, and this is just because I want them to be like that, but if you
> Wybo still don't want them to be like that, just make your proposal
> and that will be the way we'll do it. Someone have to decide, and I
> would like to do that on the UI, but, it's ok if you want to do it,
> just decide something, I want to get right into the HTML tomorrow.

I don't want to decide either, as there's something like artist-
blindness that makes pplz miss the deficits in their own designs and I
have it too of course...

So I put up an img with them side-by-side:
http://www.logilogi.org/pub/2designs.png

I'm now calling some pplz for their opinions, will report on the
results this afternoon...

Wybo

> Happy coding, and see you all later.
> 
> -- 
> Bruno

Hi all,

I'm going to be short as I had a big problem and it got too late.
While on windoze my computer went without battery because of the
outage my computer whent standby, and when waken up I started linux,
and there I worked for like 5 hours on the UI. Then when going to
sleep I wanted to do some stuff on windoze so booted and it resumed my
session, and that erased all my modified files, so no more work there
:( just share this with you becouse there where 3 more proposals but I
just had to redo only the one that I liked the most. The others where
not very good, but there where part of the process...

Anyway, there is my work, this has been a LL weekend, I guess this is
how it is going to be till we launch the new version.

My proposal D_green is a greens pallete with brown and white. The idea
is that this could be done with any color. I used the same 3 or 4
colors in all instances so it's very easy to change them in all items
at same time, just search (ctrl + f) for example fill:#a7c520 and it
selects all objects with that fill.

Also you'll see that I took back things to what I wanted them to be
like, and this is just because I want them to be like that, but if you
Wybo still don't want them to be like that, just make your proposal
and that will be the way we'll do it. Someone have to decide, and I
would like to do that on the UI, but, it's ok if you want to do it,
just decide something, I want to get right into the HTML tomorrow.

Happy coding, and see you all later.

-- 
Bruno

I just committed the xapian links-resolving :)

Unit-tests should work after a rake dev:update, rake db:dev:redo,
and then a rake test:units :)

Link resolving is now both much faster (esp with more data) and
simpler for the user as the difference between content and context 
tags is history...

Quite some work, but happy code :)

---

About the UI; there is some red-hot designing going on at the 
very moment people, we are tickling eachother to make an ever 
better design...

Currently of interest are especially (alphabetic order)

UI_proposal_B (Maybe not the coloring)
UI_proposal_C (View logi layer for top, Browsing layer for buttons)
UI_proposal_D (In the making)

They can be found in the docs svn-tree.

Wonder what you think of these, and comments are really welcome :)

I'm almost falling down with sleep, Bruno is offline due to a power-
outage, but we'll overcome all this :)

Though I'm going to get some sleep now,

Wybo

PS: No borders does look better indeed... I just committed a fix to
the View logi layer of UI_proposal_C w.o. borders and with a gradient
compromise between having the beauty of connecting lines and having 
bg-color logic...

Still we might indeed need to find some color-scheme tweaks, I agree
on that; but how big & far ? LL needs to look trustworthy and serious
for the you know project too, so it might need to be a bit less 
spacy than UI_proposal_C (& maybe D)...

> Hi Wybo,
> 
> I couldn't resist and been spending time to think about layout again,
> from things we've talk about specially, and also when applying colors
> things change a bit. Also I'm trying to follow our simplification path
> to a better UI, and I think things are getting better.

We can't resist making it better :)

I just committed UI_proposal_C.svg, in a new file basically so we can
look at them side by side...

> Here is a description of last changes:
> 
> == Colors
> First of all, I applied the current logilogi color schema. I did other
> schemas before but Wybo prefered to keep the current, so I used this
> with just a few modifications.

Nice, although it could use some betterments too. Also combining it
with new colors is not that easy (for example the darkblue around the
logis was a bit too powerfull for the current scheme).

I can't say my changes are better, but they are at least colorfull
(hope not too spicy :) and they do match with the blue.

> Buttons are sky-blue. On mouse-hover or active they are blue, like the
> active logi border.

I made them red now, and on hover they could be orange or white, or
something like that...

(I think we should only make limited use of colors for indicating
meaning, as that was what made our uis ugly, especially the previous
one (before the current))

> Logis are differentiated/associated by their blue border. When they
> are active it is darker than when not. I really like now Charls
> proposal of big-title contenders, and now they have more importance,

Good move the blue line for the selected logi, but for layout purposes
I now also made the remarks and votes with a blue line, we might
change this back though...

> Titles are dark brown and sidepanels background light brown.

Hm, they were black here... Windows/Linux

> tags: still not very convinced, have to think about them

Sure, I also left them grey as in undecided

> icons: I'll also think about this further, so we use always the same
> structure for icons, like plus, minus, X, or other icons.

Indeed, those are good. I made the help-icons blue.

> common links: links outside the logi should behave like normal links.

agree

> set's of tags: I could think of an alternative display for set of tags
> that are displayed all together, something like what I've already
> proposed, or we should have them like links, what do you think?

I've some more thoughts on this, also when no logis are found, and
will come back to this with a small update tonight...

> == Create logi and peergroup
> Well, I've proposed this before and I'm proposing this again. I
> certainly still see this should be placed this way. The new logi
> button because we want to promote the creation of logis. The peergroup
> because we need to show the importance of it.

I changed it again, as I still think it's golly ugly to have 2 buttons
floating there, but I added a permanent new logi button to the bar-
thingy now...

> == Contenders
> Again, I really like contenders as they are now, and also highlighted
> like I put them now. There is also a need for a "more contenders" link
> that would add through ajax, I'd say.

Indeed.

> Also, if I had another proposal that is a bit more radical, so I
> didn't do it. We are repeating information again. The logi has an
> image, title, rating, author, and it's listed again in the contenders
> list.  Wouldn't it be somehow nice if the logi body would contain only
> the text and leave the title, image, and rating to the side in the
> contenders list? I can imagine that flowing with ajax very nicely when
> switching contenders :) But, that for later.

Nah, what we could do is not show the current logi in the contenders
list but that would be unclear again; maybe just leave it with double
info...

> == Rating and power
> As we talked yesterday I thought we have to put this stuff together to
> make it more miningful, and that's what I did. I also took it out of
> the way somehow as the rating is in the contenders list now too.

You convinced me on this.

> == Sizes in general
> Well, I did most of the styling in the Logi-view, so the rest is not
> following exactly, but I'll define in the svg the sizes of fonts and
> so on before going into the HTML.

Indeed that still needs doing...

> I hope you all like how the UI is working out. This past week has been
> a real team work between Wybo and me, very creative process that lead
> us to this better UI. There are still differences as always, and I'd

Indeed, it is good cooperation :), pressing eachother to ever better
designs...

> like to ask for a bit of "last word" on this small details this time,
> just to give them/me a try/opportunity. Obviously I'm referring to
> position of elements, or borders, or small bits, not illogical stuff,
> and we should certainly agree in logic.

Hm... I'm kind of willing to go for the best, and I would not say that
logic always has to overrule things. Ease of use (partially logic) and 
beauty are important too...

And also of course we can't help... me neither, to want to improve...

Your design is good, and as you see most of your logi-ideas are in
UI_proposal_C, but some things were maybe logical but not beautifull,
so I moved them around a bit...

Especially buttons on panels, instead of separate.

> Looking forward your comments, going to bed soon, see you in about 8 hours.

:)

Back tonight with some small updates, especially to the
browsing-view...

Wybo

> -- 
> Bruno

Hi Wybo,

I couldn't resist and been spending time to think about layout again,
from things we've talk about specially, and also when applying colors
things change a bit. Also I'm trying to follow our simplification path
to a better UI, and I think things are getting better.

Here is a description of last changes:

== Colors
First of all, I applied the current logilogi color schema. I did other
schemas before but Wybo prefered to keep the current, so I used this
with just a few modifications.

Buttons are sky-blue. On mouse-hover or active they are blue, like the
active logi border.

Logis are differentiated/associated by their blue border. When they
are active it is darker than when not. I really like now Charls
proposal of big-title contenders, and now they have more importance,
and I like this... I would also do something similar with comments,
but that I'll think about it after release.

Titles are dark brown and sidepanels background light brown.

tags: still not very convinced, have to think about them

icons: I'll also think about this further, so we use always the same
structure for icons, like plus, minus, X, or other icons.

common links: links outside the logi should behave like normal links.

set's of tags: I could think of an alternative display for set of tags
that are displayed all together, something like what I've already
proposed, or we should have them like links, what do you think?

== Create logi and peergroup
Well, I've proposed this before and I'm proposing this again. I
certainly still see this should be placed this way. The new logi
button because we want to promote the creation of logis. The peergroup
because we need to show the importance of it.

== Contenders
Again, I really like contenders as they are now, and also highlighted
like I put them now. There is also a need for a "more contenders" link
that would add through ajax, I'd say.

Also, if I had another proposal that is a bit more radical, so I
didn't do it. We are repeating information again. The logi has an
image, title, rating, author, and it's listed again in the contenders
list.  Wouldn't it be somehow nice if the logi body would contain only
the text and leave the title, image, and rating to the side in the
contenders list? I can imagine that flowing with ajax very nicely when
switching contenders :) But, that for later.

== Rating and power
As we talked yesterday I thought we have to put this stuff together to
make it more miningful, and that's what I did. I also took it out of
the way somehow as the rating is in the contenders list now too.

== Sizes in general
Well, I did most of the styling in the Logi-view, so the rest is not
following exactly, but I'll define in the svg the sizes of fonts and
so on before going into the HTML.


I hope you all like how the UI is working out. This past week has been
a real team work between Wybo and me, very creative process that lead
us to this better UI. There are still differences as always, and I'd
like to ask for a bit of "last word" on this small details this time,
just to give them/me a try/opportunity. Obviously I'm referring to
position of elements, or borders, or small bits, not illogical stuff,
and we should certainly agree in logic.

Looking forward your comments, going to bed soon, see you in about 8 hours.

-- 
Bruno

I just added a preliminary draft for the full text search, please kick
it, as it's very drafty...

Working some more on the back-end now again (commit of models and tests 
likely tonight),

Wybo

> > So you got xapian compiled and your copy working again ? Good :)
>
> yes, I actually got the backport source list and install it through aptitude :)

Great :)

> >> == Links styling
> > Except that I don't understand what problem we have/had with remarks
> > overlapping with links, as we used to use background-color versus
> > underline already... (and they can be combined).
>
> nono, I mean solved as how I "resolved" the overlapping remarks coloring.

Ok :)

> > With comments we can use the yellow-orange range.
>
> I thought about that too, so if you agree too, I really think it's the
> way to go, since this way comments would be easier to understand as
> actual comments and not "links to other pages", while they could be
> clickable... maybe not, just popover?

I'm sorry, I used the wrong word. I meanth with remarks.

And no I still think we should show commenting logis at the bottom 
as that gives a quick overview without having to mouse-over all the
links... Quite convenient when not looking for something specific,
and also it will make things look more alive.

> > Still for the 15th of sept release I suggest we keep things simple,
> > and stick with simple blue for links, and yellow for remarks.
>
> Yes, we should unless we see we have plenty of time left :)

'k agree :)

> > As this applies to the current logi, it is not the place for a
> > contending logi adding button. We've got one at the top already, and
> > eventually could add one in the contenders-menu (but I think without
> > one there it's already clear enough).
>
> yes, good too as is better not to have same action in different flavors.

Indeed.

> >> will we change the name of comments to logi-replies? logi-comments? additions?
> >
> > Should brainstorm about this.
> >
> > Commenting logis, derived works, etc...
> >
> >> == UI svg
> >
> > Hm, I don't really think it is likely to be confused as the whole page
> > in the logi-view is about the logi, like incoming links, remarks,
> > etc...
> 
> I don't agree with this. I understand it, but I don't think people
> will understand that those stars are for the logi, and the stars from
> the bottom are for the same logi but for me to vote, and that have
> nothing to do with the comments... I really don't think so, but let's
> do it like this and see.

Seems unlikely to me that they don't get it with the 'Your rating'.

Also these should be the boxes that are like the wizzards of the page,
that show the current actions or core info. That's also why I put the
new logi button in there, really prominent.

> > So I detached it again, and put it in the small top-notice box again.
> > The reason to put it there, is to attend the user to the rating, and
> > then at the bottom, in another such box he can rate himself, making
> > the connection stand out...
>
> Again, size is not all, but ok, lets see.

'k

> > Also the small top-notice box is handy too for the browsing, and can
> > be used too (or an additional one when needed) for flash-messages...
> 
> I don't like to have the add_new_logi button inside a notice box, I
> think it should be the clear left side button I always put there :)

I see, but I think we strive for the same goal, just with different
means...

> Also notice box there is great, I will certainly go for that, but we
> should differentiate system notices (like errors, alerts, or logi
> created) from content information like "found 234 matches"

That's why I left the posibillity open for having a second one added
when there' such an alert, but having notices in notice-boxes is
indeed the idea :)

> >> have strong position and will be visible and clear, and I prefered to
> >> enphasize the create new logi link. I also removed the logi-weight,
> >
> > Isn't it already emhasized quite a bit by the little speech-cloud ?
>
> Still, I don't think it should be there the speech cloud.
> 
> This elements are adding distractions to the viewer. I think we need
> to take out of the sight as many things as possible. If we have this

Distractions ? They make the site speak, and focus on important stuff.
Liike what actions one can undertake. And they explain along the way
to new users...

> notices on mouseover users will quickly get use to this action and go
> mouse over everything, we are use to that, but if they are fixed they

Idea was to have them there statically. Either a images or as pop-
over-clouds if that is easier... So no mouse-over frenzy... :)

> will distract. Also, as you said, they could be shown (maybe all) at
> first login and vanish them after first click or something... then add
> a cookie... but imagine you navigating it from a new browser... we
> could also add a cross to close them... Still I think they should be
> only visible on mouseover, but... let's try it.

They're not that annoying... ? ;P

> >> but this could be added too, do you think it's important to be shown?
> >
> > I think it is important, as the credibility of a rating, depends on
> > it's power too (like the nrs of votes on other sites). And it is a
> > sensible place to show it, also as it clarifies, or at least suggests
> > what the user's voting-power will do.
> 
> Ok, so this brings me to other thought I had. The weight is only
> meaningful if compared with other weigh, so we should have it close to
> the user power. I don't think current position for user power is good
> over there to the right... we've lost it again from sight.

This is a point, but at least it need to be at the top too for the
credibility of the rating...

I tried to make the descriptions a bit clearer...

> > Hm, we will have to see how it works out indeed, though I think the
> > borders don't have to make it look less good perse... As they create
> > a play of lines too...
> 
> they saturate the view. http://digg.com/ http://slashdot.org/ (no borders :)

We can maybe leave out some borders, but will depend on the coloring
which...

> > So I think we do can show a (small) snippet of the logi's behind links
> > in the clouds, but that doesn't mean we can't show them at the bottom
> > too...
> 
> ok... and what do you think about having them hidden at first? like
> "See 12 comments on this logi"?

Nah, I mean the bottom of the page is not used for anything else
anyway, and pplz will expect comments ant the bottom from blogs and
such...

Wybo

> Well, I'll be working on all this later today, greetings

'k, looking forward to it :)

> -- 
> Bruno

On Thu, Sep 4, 2008 at 9:08 AM, Wybo Wiersma <wy...@lo...> wrote:
> There was a sourceforge svn outage tonight... Committing seems to be
> working now again.
>
Ok, committing now.

> So you got xapian compiled and your copy working again ? Good :)
>
yes, I actually got the backport source list and install it through aptitude :)

>> == Links styling
> Except that I don't understand what problem we have/had with remarks
> overlapping with links, as we used to use background-color versus
> underline already... (and they can be combined).
>
nono, I mean solved as how I "resolved" the overlapping remarks coloring.

> A neat addition we could have is also showing the underlines darker
> blue/more purple when there are more links, and in red when there's
> one link and no logi for it found (a dead link).

certainly :)

>
> With comments we can use the yellow-orange range.
>
I thought about that too, so if you agree too, I really think it's the
way to go, since this way comments would be easier to understand as
actual comments and not "links to other pages", while they could be
clickable... maybe not, just popover?

> Still for the 15th of sept release I suggest we keep things simple,
> and stick with simple blue for links, and yellow for remarks.
>
Yes, we should unless we see we have plenty of time left :)

>> == Logi actions
>
> Good idea :)
>
> I turned Add into Insert, and suggest the following changes:
>
> edit =>text, links, remarks, tags, settings
> insert => links, remarks, comments
>

ok, great.

> As this applies to the current logi, it is not the place for a
> contending logi adding button. We've got one at the top already, and
> eventually could add one in the contenders-menu (but I think without
> one there it's already clear enough).
>
yes, good too as is better not to have same action in different flavors.

>> will we change the name of comments to logi-replies? logi-comments? additions?
>
> Should brainstorm about this.
>
> Commenting logis, derived works, etc...
>
>> == UI svg
>
> Hm, I don't really think it is likely to be confused as the whole page
> in the logi-view is about the logi, like incoming links, remarks,
> etc...

I don't agree with this. I understand it, but I don't think people
will understand that those stars are for the logi, and the stars from
the bottom are for the same logi but for me to vote, and that have
nothing to do with the comments... I really don't think so, but let's
do it like this and see.

> So I detached it again, and put it in the small top-notice box again.
> The reason to put it there, is to attend the user to the rating, and
> then at the bottom, in another such box he can rate himself, making
> the connection stand out...
>
Again, size is not all, but ok, lets see.

> Also the small top-notice box is handy too for the browsing, and can
> be used too (or an additional one when needed) for flash-messages...
>
I don't like to have the add_new_logi button inside a notice box, I
think it should be the clear left side button I always put there :)

Also notice box there is great, I will certainly go for that, but we
should differentiate system notices (like errors, alerts, or logi
created) from content information like "found 234 matches"

>> have strong position and will be visible and clear, and I prefered to
>> enphasize the create new logi link. I also removed the logi-weight,
>
> Isn't it already emhasized quite a bit by the little speech-cloud ?
>

Still, I don't think it should be there the speech cloud.

This elements are adding distractions to the viewer. I think we need
to take out of the sight as many things as possible. If we have this
notices on mouseover users will quickly get use to this action and go
mouse over everything, we are use to that, but if they are fixed they
will distract. Also, as you said, they could be shown (maybe all) at
first login and vanish them after first click or something... then add
a cookie... but imagine you navigating it from a new browser... we
could also add a cross to close them... Still I think they should be
only visible on mouseover, but... let's try it.

>> but this could be added too, do you think it's important to be shown?
>
> I think it is important, as the credibility of a rating, depends on
> it's power too (like the nrs of votes on other sites). And it is a
> sensible place to show it, also as it clarifies, or at least suggests
> what the user's voting-power will do.
>

Ok, so this brings me to other thought I had. The weight is only
meaningful if compared with other weigh, so we should have it close to
the user power. I don't think current position for user power is good
over there to the right... we've lost it again from sight.


> Hm, we will have to see how it works out indeed, though I think the
> borders don't have to make it look less good perse... As they create
> a play of lines too...
>

they saturate the view. http://digg.com/ http://slashdot.org/ (no borders :)

>
> So I think we do can show a (small) snippet of the logi's behind links
> in the clouds, but that doesn't mean we can't show them at the bottom
> too...
>
ok... and what do you think about having them hidden at first? like
"See 12 comments on this logi"?



Well, I'll be working on all this later today, greetings

-- 
Bruno

> Hi Wybo,
> 
> == Gettext
> I fixed the errors in the gettext, but I'm getting some kind of error
> when commiting [0] so I will commit tomorrow.

There was a sourceforge svn outage tonight... Committing seems to be
working now again.

So you got xapian compiled and your copy working again ? Good :)

> == Links styling
> I also made some tests [1] of what I told you yesterday about links.
> This is just to show how I imagine them displayed and I think it looks
> nice. BTW, if you feel underlined too heavy give it a try with border
> of 1px... Also take a look at how easy the overlapping remarks are
> solved :)

Looks good :)

Except that I don't understand what problem we have/had with remarks
overlapping with links, as we used to use background-color versus
underline already... (and they can be combined).

A neat addition we could have is also showing the underlines darker
blue/more purple when there are more links, and in red when there's
one link and no logi for it found (a dead link).

With comments we can use the yellow-orange range.

Still for the 15th of sept release I suggest we keep things simple,
and stick with simple blue for links, and yellow for remarks.

> == Logi actions
> About the logi editing I got an idea from yesterday talk. We could
> show 3 type of actions buttons ( view | modiffy | add )
> 
> view => current, history, ratings, print
> edit =>text, tags, links/remarks, settings
> add => links, remarks, comments, ¿contending logi?
>
> What do you think?

Good idea :)

I turned Add into Insert, and suggest the following changes:

edit =>text, links, remarks, tags, settings
insert => links, remarks, comments

As this applies to the current logi, it is not the place for a
contending logi adding button. We've got one at the top already, and
eventually could add one in the contenders-menu (but I think without
one there it's already clear enough).

> will we change the name of comments to logi-replies? logi-comments? additions?

Should brainstorm about this.

Commenting logis, derived works, etc...

> == UI svg
> I also did some small moves in the design, not much.
> 
> I tried to link some of the logi-metadata to the logi itself by
> snapping them to it and make sure they don't get confused with other
> elements. Also made them a little bit smaller, as I think ratings will

Hm, I don't really think it is likely to be confused as the whole page
in the logi-view is about the logi, like incoming links, remarks,
etc...

So I detached it again, and put it in the small top-notice box again.
The reason to put it there, is to attend the user to the rating, and
then at the bottom, in another such box he can rate himself, making
the connection stand out...

Also the small top-notice box is handy too for the browsing, and can
be used too (or an additional one when needed) for flash-messages...

> have strong position and will be visible and clear, and I prefered to
> enphasize the create new logi link. I also removed the logi-weight,

Isn't it already emhasized quite a bit by the little speech-cloud ?

> but this could be added too, do you think it's important to be shown?

I think it is important, as the credibility of a rating, depends on
it's power too (like the nrs of votes on other sites). And it is a
sensible place to show it, also as it clarifies, or at least suggests
what the user's voting-power will do.

> Also, without borders the nav bars and tabs looks better, but this
> will be defined whith the rest of the styling and coloring, will get
> into this tomorrow and hope to start with html too.

Hm, we will have to see how it works out indeed, though I think the
borders don't have to make it look less good perse... As they create
a play of lines too...

> I still will work on defining the elements and that we could do it
> toghether during the day if you are available, at least to check what
> I'm doing and give opinions and this way we might finally define all
> pages elements.

I am available :)

(& mostly working on the back-end tests)

> I think we've done a great job already taking elements away from the
> view and make things more clear, but we should keep this in mind
> still... the logi view is a bit crowled, and I've been actually
> thinking about removing the comments and show them directly in the
> link-popovers, like links that can be expanded... If they are still a
> short snippet... This might be radical, but it might work, and is
> really meaningful for explaining where the debate is going on.

I would not be for only showing them in the clouds, as just like with
remarks it might be good to also allow commenting logis that are not
attached to a part of text.

And besides, at the bottom of the page, out of the first sight,
croudedness is not a problem, and even a feature, as logi's will look
more used, more active, when there's lots of comments / remarks / 
votes below & besides them...

So I think we do can show a (small) snippet of the logi's behind links
in the clouds, but that doesn't mean we can't show them at the bottom
too...

> I'm sending you the file as I cannot commit to SF.net I also think we
> should work on the same file and if we don't like some change just
> checkout previous version and import elements (or copy the xml text :)

Just did that. And we might indeed now be in a phase with the design
of the browse and logi view pages where we can do this, though it can
be handy too to have 2 files, that can be opened side by side...

But I went with it now, and committed in UI_proposal_B.svg,

Wybo

PS: I like the change in grayscale in the buttons so also applied it
to the browsing view... :)

Hi Wybo,

== Gettext
I fixed the errors in the gettext, but I'm getting some kind of error
when commiting [0] so I will commit tomorrow.

== Links styling
I also made some tests [1] of what I told you yesterday about links.
This is just to show how I imagine them displayed and I think it looks
nice. BTW, if you feel underlined too heavy give it a try with border
of 1px... Also take a look at how easy the overlapping remarks are
solved :)

== Logi actions
About the logi editing I got an idea from yesterday talk. We could
show 3 type of actions buttons ( view | modiffy | add )

view => current, history, ratings, print
edit =>text, tags, links/remarks, settings
add => links, remarks, comments, ¿contending logi?

What do you think?

will we change the name of comments to logi-replies? logi-comments? additions?

== UI svg
I also did some small moves in the design, not much.

I tried to link some of the logi-metadata to the logi itself by
snapping them to it and make sure they don't get confused with other
elements. Also made them a little bit smaller, as I think ratings will
have strong position and will be visible and clear, and I prefered to
enphasize the create new logi link. I also removed the logi-weight,
but this could be added too, do you think it's important to be shown?

Also, without borders the nav bars and tabs looks better, but this
will be defined whith the rest of the styling and coloring, will get
into this tomorrow and hope to start with html too.

I still will work on defining the elements and that we could do it
toghether during the day if you are available, at least to check what
I'm doing and give opinions and this way we might finally define all
pages elements.

I think we've done a great job already taking elements away from the
view and make things more clear, but we should keep this in mind
still... the logi view is a bit crowled, and I've been actually
thinking about removing the comments and show them directly in the
link-popovers, like links that can be expanded... If they are still a
short snippet... This might be radical, but it might work, and is
really meaningful for explaining where the debate is going on.

I'm sending you the file as I cannot commit to SF.net I also think we
should work on the same file and if we don't like some change just
checkout previous version and import elements (or copy the xml text :)

I hope to be a productive day tomorrow, talk to you later.

[0] svn: MKACTIVITY of
'/svnroot/logilogi/!svn/act/4b00f4fa-6a53-497f-b3b6-ff7e56756b37': 403
Forbidden (https://logilogi.svn.sourceforge.net)
[1] http://logilogi.overbits.com/links.html
-- 
Bruno

Also, I've just seen your additions to the svg and they all look
awesom... good work! I'll work over that.

On Wed, Sep 3, 2008 at 5:41 PM, Bruno <bs...@gm...> wrote:
> Hi all,
>
> On Wed, Sep 3, 2008 at 1:57 PM, Wybo Wiersma <wy...@lo...> wrote:
>>> As things go forward, another UI-proposal. This one is called
>>> UI_proposal_lattice_tags.svg, again to be found in the docs svn.
>>
>> I added some small improvements again, in the details. Made it more
>> face 2 face by adding pictures of authors (a good idea from
>> UI_Proposal_A).
>>
>> I haven't been able to do as much as I liked because of the rather
>> painfull removal of my last wisdom-tooth (mandibular third molar). I
>> even had some fever because of it. Hope to be back at full speed
>> tomorrow...
>>
> Ouch, tooth pain is annoying... hope you get better from this :)
>
> I've also been absent last days as a friend come to visit... I thought
> I'd have more time but that was not realistic... :P
>
>> Bruno if you want you can already start modifying the UI, but to view
>> it the gettext errors will need to be cleared. Any success with that
>> already ?
>>
> I will, we're behind schedule... I'll first work over the svg a little
> more and share and get your feedback and then tonight or tomorrow
> start with the actual coding.
>
>> Wybo
>>
>
>
> Talk later.
>
>
> --
> Bruno
>



-- 
Bruno

Hi all,

On Wed, Sep 3, 2008 at 1:57 PM, Wybo Wiersma <wy...@lo...> wrote:
>> As things go forward, another UI-proposal. This one is called
>> UI_proposal_lattice_tags.svg, again to be found in the docs svn.
>
> I added some small improvements again, in the details. Made it more
> face 2 face by adding pictures of authors (a good idea from
> UI_Proposal_A).
>
> I haven't been able to do as much as I liked because of the rather
> painfull removal of my last wisdom-tooth (mandibular third molar). I
> even had some fever because of it. Hope to be back at full speed
> tomorrow...
>
Ouch, tooth pain is annoying... hope you get better from this :)

I've also been absent last days as a friend come to visit... I thought
I'd have more time but that was not realistic... :P

> Bruno if you want you can already start modifying the UI, but to view
> it the gettext errors will need to be cleared. Any success with that
> already ?
>
I will, we're behind schedule... I'll first work over the svg a little
more and share and get your feedback and then tonight or tomorrow
start with the actual coding.

> Wybo
>


Talk later.


-- 
Bruno

> As things go forward, another UI-proposal. This one is called 
> UI_proposal_lattice_tags.svg, again to be found in the docs svn.

I added some small improvements again, in the details. Made it more
face 2 face by adding pictures of authors (a good idea from
UI_Proposal_A).

I haven't been able to do as much as I liked because of the rather
painfull removal of my last wisdom-tooth (mandibular third molar). I
even had some fever because of it. Hope to be back at full speed
tomorrow...

Bruno if you want you can already start modifying the UI, but to view
it the gettext errors will need to be cleared. Any success with that
already ?

Wybo

As things go forward, another UI-proposal. This one is called 
UI_proposal_lattice_tags.svg, again to be found in the docs svn.

It was based on both Bruno's changes to the
UI_proposal_Tags3_Search_View.svg and on the initial version of 
this file...

The top is clearer now (more logical, although I still kept an eye
on beauty...), and the bar is now filled with grey, instead of the 
bars inside. The menu's have matching title-sections, and a logi-
view has been added too in a second layer (I reduced the number of 
layers to 3, from UI_proposal_Tags3_Search_View).

Note that especially the logi view is still very much a draft and many
parts are not filled in yet, like the edit-buttons and the recent
votes.

Hope u like it Bruno and Miguel,

Open for improvements (& now back @ back-end work),

Wybo

> All,
> 
> I've just made some work over the browsing/searching interfase. Sorry
> I couldn't be so simplistic to just type text in, but I needed to put
> things there to start reducing the elements at sight, and I think I
> succeeded in part.

Ok, agree. Especially as we largely agree on what's to be in there...

(apart from some minor things maybe, like tabs :)

What I like is that you removed the power from the peergroup-selection
and the matches here, as indeed this is no relevant info when browsing
:)

> You'll find two new proposals here.

Hm, I only found one, also no layers in the file..?

> The search/browsing. This are the two known approaches to knowledge
> finding and I thought we should have them side by side. Also I started

Love this, the tabs for searching and browsing! :)

But maybe we can add Logi too, as there will be contenders too then
and it seems reasonable to me to keep the query around when clicking
into a logi.

> questioning how we would handle (with the search on top right) when we
> did a text search, what where we going to do with the tag search? I
> thought this was going to be a problem, and this solution I think is a
> good one, we could even save tag-browsing while on text-search.

Agree :)

> The other suggestion is menues next to the title, as this would reduce
> visual elements and still have them handy on just mouse over.

I think this is a bit a weird approach, having the main menu in a
drop-down. Also it might confuse users as they would not know where
they are relative to other pages...

I got a small suggestion for this further in this mail.

> Also, while there is a lot of design, this is just a quick display of
> the elements. Also this elements are the basics and with them we can
> quickly do the rest of the pages displays.

Good, I like many things from this design, for example also the minus
and plus signs behind the tags, for adding and removing them; well
done, and real teamwork :)

(I moved the minus-sign in the icons behind the tags a bit more to the
center, and I removed them from the tags in the snippet as, from how I 
understand they are not meanth to be removed from there if I'm right.
These are small fixes to the tag_browsing_draft.svg)

Besides this in another file I've done some small re-arrangements and 
tweaks this morning, and committed it as UI_proposal_Tags3_Search_View
in docs.

The most important improvements / changes are that it is a bit more 
spacious, that the peergroup selector is now inside the line around
the tag-browsing, that the textfield for manually adding tags is
behind the tags, and suggested is a "two-stage tabs dashboard", really
nifty :)

I've not added any coloring yet, but made some differences with
grayscales, much like in the tag_browsing_draft. And the
UI_proposal_Tags3_Search_View is a draft too of course... But the
designs are already becoming better :)

Wybo

> Have to go now, talk to all tomorrow.

'k I will do some more back-end work untill we meet again this
afternoon / night... Really looking forward to your comments :)

> -- 
> Bruno

All,

I've just made some work over the browsing/searching interfase. Sorry
I couldn't be so simplistic to just type text in, but I needed to put
things there to start reducing the elements at sight, and I think I
succeeded in part.

You'll find two new proposals here.

The search/browsing. This are the two known approaches to knowledge
finding and I thought we should have them side by side. Also I started
questioning how we would handle (with the search on top right) when we
did a text search, what where we going to do with the tag search? I
thought this was going to be a problem, and this solution I think is a
good one, we could even save tag-browsing while on text-search.

The other suggestion is menues next to the title, as this would reduce
visual elements and still have them handy on just mouse over.

Also, while there is a lot of design, this is just a quick display of
the elements. Also this elements are the basics and with them we can
quickly do the rest of the pages displays.

Have to go now, talk to all tomorrow.

-- 
Bruno

> Hi Wybo,
> 
> I really like this aproach, we are injecting simplicity and
> flexibility to LL and this is esential for usability, we are heading
> the right way.

:)

> I'm already having some visions :) about the UI for this and I'd like
> to ask some details... As from your link example, I see that there
> will be giving the user the posibility to add either content or
> context tags (in the old concept)... I think this should also be the
> way to navigate through logis, and I'll make a graphical proposal
> about this.

Hm, the idea here is/was that for navigation we only need one cloud,
with a reset-button, to remove the accumulated tags in the query.

As apart from the exact-tag-order matches, tag-order does not matter
any more for the navigation with this smart-lattice approach.

That was/is how it is supposed to be simpler :)

But I'm looking forward to your UI-proposal,

Wybo

> Back to the IRC now :)
> 
> greetings!
> 
> On Thu, Aug 28, 2008 at 7:51 AM, Wybo Wiersma <wy...@lo...> wrote:
> >
> > After another IRC-conversation with Bruno, I think we can make things
> > even simpler, without losing important features & while gaining a lot
> > of clarity...
> >
> > What if for the navigation we used a normal concept-lattice: that is
> > have only one type of tags, while still giving logis a fixed tag-order,
> > and telling the user the first tag is most important.
> >
> > First the concept lattice will:
> > * Make the cloud fuller even with little content, as all tags are used
> >  inside it
> > * Make finding things easier, as Aristotle, History and History,
> >  Aristotle would show up when browsing to History, Aristotle.
> >
> > Secondly the fixed tag-order for the logi's link will
> > * Provide stabillity, and via links induce sensible tagging by default.
> >
> > This because when adding a link we could show 2 options to the user:
> >
> > * To a more specific sub-tag
> >
> > Aristotle , Philosophy , |_     | (user can key in Ethics for example)
> >
> > * Or to somewhere else
> >
> > |_     | , Philosophy (user can key in Sartre)
> >
> > (and there is a reset sub-tags button)
> >
> > Also when navigating there can be - behind the scenes - 2 searches.
> > One for the exact tag-order "History, Aristotle", and one for the tags
> > in any order, and with other sub-tags if needed...
> >
> > Results from this first search will then always be shown first, no
> > matter their rating, followed by the other results.
> >
> > The advantage of this smart lattice-approach is that to the user it
> > just are tags, plain and simple, and in the search-layer too, so we
> > just need one cloud there, while the specialization of logis is still
> > possible and easy, and their locations rather stable...
> >
> > What do you Bruno & others think of this ?
> >
> > greetings,
> >
> > Wybo
> >
> > > ---
> > >
> > > Besides that I have been thinking about the context-content links
> > > stuff and about how complicated it all is to unsuspecting visitors, so
> > > we (Bruno and I) 'd like to make it simpler...
> > >
> > > What I'd like to propose is first of all to - for now again - only
> > > allow one tag-set per logi... Something like 'Aristotle, History, Life'
> > >
> > > This tag-set will be the fixed location of the logi, and still multiple
> > > logis can have the same tag-set (that is there still are contenders).
> > >
> > > Also still some tags are more important than others, that is we still
> > > have content- and context-tags, but for clarity we could call them the
> > > primary tag, and context-tags.
> > >
> > > Users visiting LogiLogi will, on the mainpage see a cloud with all
> > > primary tags, so at least Aristotle in this example.
> > >
> > > Then, they can click a primary tag, giving them the url /Aristotle.
> > > They then will see a new, smaller cloud, below the url, on the right.
> > > In this cloud the context-tags are shown (History and Life in this
> > > example). Below the url on the left are snippets of all logis that
> > > have Aristotle as their primary tag, sorted by their rating (for the
> > > user's selected peergroup). Visitors can click on one immediately.
> > >
> > > When they like to narrow their search, they can also click one of the
> > > context-tags in the smaller cloud (for example Life), and then a new
> > > query is made, showing only the logis that have Aristotle as their
> > > primary tag, and Life as one of their context-tags.
> > >
> > > The 2 assumptions behind this proposal are
> > > - that people, when looking for a page start vague, but with the
> > >   subject, and then narrow down accordingly.
> > > - that it's good to keep things entity oriented; to draw different
> > >   Logi's on each subject (like Aristotle) together, and to keep things
> > >   easily navigatable... This should lead to interesting discussions.
> > >
> > > In this proposal there will still be requested and received url-bars
> > > in the logi-view, but not in the search-view. In the logi-view (also
> > > shown when there is only one logi for a set of searched for tags &
> > > no logi's below it in the tree) the requested url-bar will contain the
> > > tags of the query, while the received url-bar will contain the tags
> > > used when the logi was created (also in the order then used). Some-
> > > times this can be more (or less, when the user typed them directly)
> > > tags than were in the query.
> > >
> > > This allows new people to - when creating new logis - put things in
> > > the same or simmilar places as earlier logis, thereby making it easier
> > > to keep things clean than not...
> > >
> > > To make this even stronger, also when adding links to a logi, by
> > > default the context tags of the logi being added are already filled in
> > > for the new link. So a link from Aristotle, History to Socrates, will,
> > > without user-interaction be to Socrates, History. This; be it that it
> > > is in reversed tag-order now, was something that really worked well in
> > > the old version of LogiLogi, but now, with easy navigation it will
> > > work even better!
> > >
> > > An additional advantage of this approach is that we can use Ferret (or
> > > a better search lib) for most of the searching with this method, so it
> > > will also scale very well... (the only moderately slow thing will be
> > > the generation of the clouds).
> > >
> > > Fully implementing & testing this proposal in the back-end will take,
> > > I think between 1 and 2 weeks, so not too bad either.
> > >
> > > I will do some more pondering about it, but I was just wondering what
> > > you pplz (Bruno, Miguel & the others) think of it...
> > >
> > > Wybo
> > >
> > > PS: Yup it will be primary-tag first, instead of primary tag last, as
> > > was currently the case in the url & in the old version of LogiLogi. I
> > > was still thinking about it the other way when we chatted yesterday
> > > Bruno, but I guess some things you said, changed my mind...
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK & win great prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > LogiLogi-list mailing list
> > Log...@li...
> > https://lists.sourceforge.net/lists/listinfo/logilogi-list
> 
> 
> 
> --
> Bruno
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> LogiLogi-list mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/logilogi-list
> 

-- 
---

::Student:
- Informatiekunde (computer linguistics, IR, webtech), History and Philosophy
- Member of the Center for Metahistory Groningen (http://www.rug.nl/let/cmg)

::Free Software and Open Source Developer:
- Active in the LogiLogi Foundation (http://foundation.logilogi.org)
- http://www.LogiLogi.org, Cumulative, shared commenting, publication and 
                           idea sharing: Where insight comes together...
- http://www.OgOg.org, RSS feed articles rating, a meritocracy...
- ComLinToo, a computational linguistics toolset written in Perl

Hi Wybo,

I really like this aproach, we are injecting simplicity and
flexibility to LL and this is esential for usability, we are heading
the right way.

I'm already having some visions :) about the UI for this and I'd like
to ask some details... As from your link example, I see that there
will be giving the user the posibility to add either content or
context tags (in the old concept)... I think this should also be the
way to navigate through logis, and I'll make a graphical proposal
about this.

Back to the IRC now :)

greetings!

On Thu, Aug 28, 2008 at 7:51 AM, Wybo Wiersma <wy...@lo...> wrote:
>
> After another IRC-conversation with Bruno, I think we can make things
> even simpler, without losing important features & while gaining a lot
> of clarity...
>
> What if for the navigation we used a normal concept-lattice: that is
> have only one type of tags, while still giving logis a fixed tag-order,
> and telling the user the first tag is most important.
>
> First the concept lattice will:
> * Make the cloud fuller even with little content, as all tags are used
>  inside it
> * Make finding things easier, as Aristotle, History and History,
>  Aristotle would show up when browsing to History, Aristotle.
>
> Secondly the fixed tag-order for the logi's link will
> * Provide stabillity, and via links induce sensible tagging by default.
>
> This because when adding a link we could show 2 options to the user:
>
> * To a more specific sub-tag
>
> Aristotle , Philosophy , |_     | (user can key in Ethics for example)
>
> * Or to somewhere else
>
> |_     | , Philosophy (user can key in Sartre)
>
> (and there is a reset sub-tags button)
>
> Also when navigating there can be - behind the scenes - 2 searches.
> One for the exact tag-order "History, Aristotle", and one for the tags
> in any order, and with other sub-tags if needed...
>
> Results from this first search will then always be shown first, no
> matter their rating, followed by the other results.
>
> The advantage of this smart lattice-approach is that to the user it
> just are tags, plain and simple, and in the search-layer too, so we
> just need one cloud there, while the specialization of logis is still
> possible and easy, and their locations rather stable...
>
> What do you Bruno & others think of this ?
>
> greetings,
>
> Wybo
>
> > ---
> >
> > Besides that I have been thinking about the context-content links
> > stuff and about how complicated it all is to unsuspecting visitors, so
> > we (Bruno and I) 'd like to make it simpler...
> >
> > What I'd like to propose is first of all to - for now again - only
> > allow one tag-set per logi... Something like 'Aristotle, History, Life'
> >
> > This tag-set will be the fixed location of the logi, and still multiple
> > logis can have the same tag-set (that is there still are contenders).
> >
> > Also still some tags are more important than others, that is we still
> > have content- and context-tags, but for clarity we could call them the
> > primary tag, and context-tags.
> >
> > Users visiting LogiLogi will, on the mainpage see a cloud with all
> > primary tags, so at least Aristotle in this example.
> >
> > Then, they can click a primary tag, giving them the url /Aristotle.
> > They then will see a new, smaller cloud, below the url, on the right.
> > In this cloud the context-tags are shown (History and Life in this
> > example). Below the url on the left are snippets of all logis that
> > have Aristotle as their primary tag, sorted by their rating (for the
> > user's selected peergroup). Visitors can click on one immediately.
> >
> > When they like to narrow their search, they can also click one of the
> > context-tags in the smaller cloud (for example Life), and then a new
> > query is made, showing only the logis that have Aristotle as their
> > primary tag, and Life as one of their context-tags.
> >
> > The 2 assumptions behind this proposal are
> > - that people, when looking for a page start vague, but with the
> >   subject, and then narrow down accordingly.
> > - that it's good to keep things entity oriented; to draw different
> >   Logi's on each subject (like Aristotle) together, and to keep things
> >   easily navigatable... This should lead to interesting discussions.
> >
> > In this proposal there will still be requested and received url-bars
> > in the logi-view, but not in the search-view. In the logi-view (also
> > shown when there is only one logi for a set of searched for tags &
> > no logi's below it in the tree) the requested url-bar will contain the
> > tags of the query, while the received url-bar will contain the tags
> > used when the logi was created (also in the order then used). Some-
> > times this can be more (or less, when the user typed them directly)
> > tags than were in the query.
> >
> > This allows new people to - when creating new logis - put things in
> > the same or simmilar places as earlier logis, thereby making it easier
> > to keep things clean than not...
> >
> > To make this even stronger, also when adding links to a logi, by
> > default the context tags of the logi being added are already filled in
> > for the new link. So a link from Aristotle, History to Socrates, will,
> > without user-interaction be to Socrates, History. This; be it that it
> > is in reversed tag-order now, was something that really worked well in
> > the old version of LogiLogi, but now, with easy navigation it will
> > work even better!
> >
> > An additional advantage of this approach is that we can use Ferret (or
> > a better search lib) for most of the searching with this method, so it
> > will also scale very well... (the only moderately slow thing will be
> > the generation of the clouds).
> >
> > Fully implementing & testing this proposal in the back-end will take,
> > I think between 1 and 2 weeks, so not too bad either.
> >
> > I will do some more pondering about it, but I was just wondering what
> > you pplz (Bruno, Miguel & the others) think of it...
> >
> > Wybo
> >
> > PS: Yup it will be primary-tag first, instead of primary tag last, as
> > was currently the case in the url & in the old version of LogiLogi. I
> > was still thinking about it the other way when we chatted yesterday
> > Bruno, but I guess some things you said, changed my mind...
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> LogiLogi-list mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/logilogi-list



--
Bruno

After another IRC-conversation with Bruno, I think we can make things
even simpler, without losing important features & while gaining a lot
of clarity...

What if for the navigation we used a normal concept-lattice: that is
have only one type of tags, while still giving logis a fixed tag-order,
and telling the user the first tag is most important.

First the concept lattice will:
* Make the cloud fuller even with little content, as all tags are used
  inside it
* Make finding things easier, as Aristotle, History and History,
  Aristotle would show up when browsing to History, Aristotle.

Secondly the fixed tag-order for the logi's link will
* Provide stabillity, and via links induce sensible tagging by default.

This because when adding a link we could show 2 options to the user:

* To a more specific sub-tag

Aristotle , Philosophy , |_     | (user can key in Ethics for example)

* Or to somewhere else

|_     | , Philosophy (user can key in Sartre)

(and there is a reset sub-tags button)

Also when navigating there can be - behind the scenes - 2 searches.
One for the exact tag-order "History, Aristotle", and one for the tags
in any order, and with other sub-tags if needed...

Results from this first search will then always be shown first, no
matter their rating, followed by the other results.

The advantage of this smart lattice-approach is that to the user it
just are tags, plain and simple, and in the search-layer too, so we
just need one cloud there, while the specialization of logis is still
possible and easy, and their locations rather stable...

What do you Bruno & others think of this ?

greetings,

Wybo

> ---
> 
> Besides that I have been thinking about the context-content links
> stuff and about how complicated it all is to unsuspecting visitors, so
> we (Bruno and I) 'd like to make it simpler...
> 
> What I'd like to propose is first of all to - for now again - only
> allow one tag-set per logi... Something like 'Aristotle, History, Life'
> 
> This tag-set will be the fixed location of the logi, and still multiple 
> logis can have the same tag-set (that is there still are contenders).
> 
> Also still some tags are more important than others, that is we still
> have content- and context-tags, but for clarity we could call them the
> primary tag, and context-tags.
> 
> Users visiting LogiLogi will, on the mainpage see a cloud with all
> primary tags, so at least Aristotle in this example.
> 
> Then, they can click a primary tag, giving them the url /Aristotle.
> They then will see a new, smaller cloud, below the url, on the right.
> In this cloud the context-tags are shown (History and Life in this
> example). Below the url on the left are snippets of all logis that
> have Aristotle as their primary tag, sorted by their rating (for the
> user's selected peergroup). Visitors can click on one immediately.
> 
> When they like to narrow their search, they can also click one of the
> context-tags in the smaller cloud (for example Life), and then a new 
> query is made, showing only the logis that have Aristotle as their 
> primary tag, and Life as one of their context-tags.
> 
> The 2 assumptions behind this proposal are
> - that people, when looking for a page start vague, but with the
>   subject, and then narrow down accordingly.
> - that it's good to keep things entity oriented; to draw different
>   Logi's on each subject (like Aristotle) together, and to keep things 
>   easily navigatable... This should lead to interesting discussions.
> 
> In this proposal there will still be requested and received url-bars
> in the logi-view, but not in the search-view. In the logi-view (also
> shown when there is only one logi for a set of searched for tags &
> no logi's below it in the tree) the requested url-bar will contain the
> tags of the query, while the received url-bar will contain the tags
> used when the logi was created (also in the order then used). Some-
> times this can be more (or less, when the user typed them directly) 
> tags than were in the query.
> 
> This allows new people to - when creating new logis - put things in
> the same or simmilar places as earlier logis, thereby making it easier
> to keep things clean than not...
> 
> To make this even stronger, also when adding links to a logi, by
> default the context tags of the logi being added are already filled in
> for the new link. So a link from Aristotle, History to Socrates, will,
> without user-interaction be to Socrates, History. This; be it that it
> is in reversed tag-order now, was something that really worked well in
> the old version of LogiLogi, but now, with easy navigation it will
> work even better!
> 
> An additional advantage of this approach is that we can use Ferret (or
> a better search lib) for most of the searching with this method, so it
> will also scale very well... (the only moderately slow thing will be
> the generation of the clouds).
> 
> Fully implementing & testing this proposal in the back-end will take, 
> I think between 1 and 2 weeks, so not too bad either.
> 
> I will do some more pondering about it, but I was just wondering what
> you pplz (Bruno, Miguel & the others) think of it...
> 
> Wybo
> 
> PS: Yup it will be primary-tag first, instead of primary tag last, as
> was currently the case in the url & in the old version of LogiLogi. I
> was still thinking about it the other way when we chatted yesterday
> Bruno, but I guess some things you said, changed my mind...

> Well, I've been doing this _("") adding stuff... :)
> 
> I hope there are not too many un-closed parenthesis or errors as I
> couldn't test it on my local copy.

I have ran rake gettext:harvest and I got no errors there...

What error / problem are you encountering ? Note that you should have
the gettext-package installed on ubuntu, and the gettext-gem.

(we can discuss it over IRC, but at least Manta should be able to run
with gettext and xapian on debian-based distro's and preferably on
other distro's and the mac too (using FF for the front-end))

> I used as standard not to include characters like ":" after "Step 1"
> for example, so if we decide to remove/add it we just have to take it
> out in the code and not in every language.

Ok, that's good :)

> Also I found some possible problems with a pluralize() function...
> will this function pluralize words like "time" to "times"? how will it
> do it in spanish? :)

It will not work in spanish, so the pluralize will have to be replaced
by a (@somethings > 1 ? _('somethings') : _('something'))

> I also had some situations like the following that need variables so
> can be moved as have different position in different languages:
> <%= _("Remove the %{peer_group_ll_link} peergroup")
> %{:peer_group_ll_link => peer_group_ll_link(@peer_group)} %>

These are good. In the translation the translator will have to move
the %{peer_group_ll_link} around in the translation-string.

> I also did this one: <%= _("You can %{link_to}") %{:link_to =>
> (link_to _('get an account here'), signup_sessions_url)} %>
> 
> I hope they are oK .. :P In case it's wrong, the pattern to search for
> all of them would be grep -Hnr "%{:" *

I hot no errors so I assume it works correctly...

> I also modified the order of the cancel buttons in the panels so it
> would not cancel when hitting return, but I'm not sure if changing the
> order of display will just do or need to set some tab-index in the
> modal box settings...

Hm, that does not seem a good idea to me as it is some kind of
unwritten standard (at least for Windows and Sun) that cancel-buttons 
are on the right...

So we can best set the tab-order (but the overboxes are going to go
anyway, so we will come back to this).

> About the proposal I still have to finish it up, but that will be
> tomorrow for sure, so hope we can comment on it tomorrow too.

Ok.

> Then we should take some days (not many) to define our next release
> elements on pages, and on that re-organize the user interface. In your
> last proposal Wybo, there has been a radical spin on the tags
> approach, which I mostly like and will be doing some additions, and
> will add some minimalism to it, and also to the entire interface. We
> need to take things out of the way, and we will do it and succeed on
> this... But, not tonight, maybe the day after tomorrow I'll start
> writing the specifications and after that start drawing... (by the
> way, svg UI drwaing is great way to explain right? :)

Agree.

In the meantime I will start making the needed changes in the back-
end. Will still take some time, but I am already booking progress.

Wybo

> Greetings all.
> 
> -- 
> Bruno

Well, I've been doing this _("") adding stuff... :)

I hope there are not too many un-closed parenthesis or errors as I
couldn't test it on my local copy.

I used as standard not to include characters like ":" after "Step 1"
for example, so if we decide to remove/add it we just have to take it
out in the code and not in every language.

Also I found some possible problems with a pluralize() function...
will this function pluralize words like "time" to "times"? how will it
do it in spanish? :)

I also had some situations like the following that need variables so
can be moved as have different position in different languages:
<%= _("Remove the %{peer_group_ll_link} peergroup")
%{:peer_group_ll_link => peer_group_ll_link(@peer_group)} %>

I also did this one: <%= _("You can %{link_to}") %{:link_to =>
(link_to _('get an account here'), signup_sessions_url)} %>

I hope they are oK .. :P In case it's wrong, the pattern to search for
all of them would be grep -Hnr "%{:" *

I also modified the order of the cancel buttons in the panels so it
would not cancel when hitting return, but I'm not sure if changing the
order of display will just do or need to set some tab-index in the
modal box settings...

About the proposal I still have to finish it up, but that will be
tomorrow for sure, so hope we can comment on it tomorrow too.

Then we should take some days (not many) to define our next release
elements on pages, and on that re-organize the user interface. In your
last proposal Wybo, there has been a radical spin on the tags
approach, which I mostly like and will be doing some additions, and
will add some minimalism to it, and also to the entire interface. We
need to take things out of the way, and we will do it and succeed on
this... But, not tonight, maybe the day after tomorrow I'll start
writing the specifications and after that start drawing... (by the
way, svg UI drwaing is great way to explain right? :)

Greetings all.

-- 
Bruno