It's really great to check the mail and see that there is a UI
proposal for LL, thanks!
We'll (I hope) talk further about this proposal and the UI in general,
but for now I'll be short, as I'm moving to another house tomorrow
(sadly not a hose but a hostel), so I'm running out of time, but I
don' want to miss the oportunity to comment on your work, as I know
the faster the comments, the faster you'll process new ideas.
I'd like to express different opinions, from different points of
view... (I love LL)
Overall: You made a more clean (of stuff) UI. This is something you've
been talking from the begining and I think it worked out right, I
think it definitely helps the usability to have less choices. You also
choosed to move to a contemporary "blog-style" layout, which will be
friendly to anybody who browses the web nowadays, which is also a safe
decision in terms of usability. About the browsing, I would have to
test the search box final proposal, but I thought you meant to do
something different from some other comments you made. I thought there
would be different alternatives of tags sets, which I think it's a
good idea. Maybe it was just that I understood it and it was not ment
to be that way.
In summary, you've created a more standard view of logilogi which will
get the user more confortable, however, I see we have to work towards
a more participative, didactic UI. I also liked the context-related
display of components.
Graphic: I personally prefer other kind of color schemes. To get some
more 2.0 style, I'd play some more with font sizes, like getting the
most important stuff just plain bigger, like the query box (as flikr
for example). My advice in general (from design view), would be to
standarize a little more. Get all links to be underlined blue (I see
they are like this now, but are tags clickable?). Get the buttons to
be always the same too. Is the logi text bold? Get more contrast for
tabs and show which one is current. (you'll get crazy if you're
looking for rounded tabs, css lists crossbrowser :) About colors, I'd
suggest you get actually White space, not just empty space. But this
is in some point personal, as you've seen in my proposal, I like black
over white for most text, and left color for grouping. We should study
further about contrast, best reading displays, etc...
I really don't have the time now, but I'd like to write back in a
couple of days with a more insightful commenting on your work.
I found very interesting when you all proposed ideas and points of
view. We need this exchange. This part of the work was like a parallel
work between LL and Gip, and now we still have to get both parts
together in the LL release, which will take a lot more of exchange of
ideas and planning of what next LL UI will be. I'll go now, and just
want to say that I'm really happy of working with you all in this
On 6/29/07, Wybo Wiersma <wybo@...> wrote:
> My exam went well, and now the more extensive comments...
> > http://logilogi.wiki.sourceforge.net/GipDesign
> > I will fully reply to it tomorrow evening as I have to contemplate about it a
> > bit more, and I am also having an exam tomorrow at the end of the day...
> My impression is that it is a fine UI, something we definitely can
> use, but also something that needs quite some changes still before we
> can call it the UI of Manta. Also I would like to hear what Bruno
> thinks of it. If it is something he could work with.
> Besides this I am also looking forward to seeing the HTML+CSS+JS
> online somewhere. But first the comments and issues...:
> > > "As you can see, the viewport is roughly divided into four areas: a header,
> > > the main area which itself is divided into space for the logi, and a
> > > sidebar, and finally at the bottom there is a footer. The overall design
> > > follows web 2.0 ideology of simplicity, ease of use, lots of white space,
> > > minimalistic approach. A main feature is the fact that most ui-elements like
> > > toolbars and certain contextual panels are only shown on-demand and in
> > > context. For example, the toolbar to 'do things with a logi' is only shown
> > > when the reader/user wishes to 'do things with the logi'. Leaving it out,
> > > per default, cleans up much of the design. Also, panels like peer group
> > > preferences or other 'advanced' uses are naturally left out when the visitor
> > > is not yet logged in.
> The basic approach is ok, and especially early on I think it will be
> no problem that not-logged in users cannot have a pick on what peer-
> group, or user-group they want to use.
> > (Note in Dutch about it already being integrated in a local working-copy
> > of Manta. Also it does not work fully yet in IE)
> The integration effort is a bit at crossroads with the version without
> senses that will be integrated in the trunk soon. So part of this work
> might be lost...
> > > I fully concur with the idea to have multiple levels of complexity for the
> > > interface, but at the same time limiting the number of those levels to three
> > > or even two. One way is to have the user explicitly state the preferred mode
> > > of the interface. Another way is to in- and exclude elements on-demand or to
> > > have logilogi 'be smart' as to whether to show certain things at a certain
> > > moment.
> Fully agree, I would prefer to keep settings to 2 levels for now, and
> besides that be smart with coloring and what we do and don't show.
> > > I would like to mention some notable concepts in the interface as I
> > > envision, and which also summarize our joint ideas (as I understand them):
> > >
> > > 1. Simple and minimalistic viewport composition. Just four areas of concern:
> > > the header, logi, sidebar for contextual navigation etc, footer.
> > >
> > > 2. Logilogi's primary use is reading and navigating logis. In the concepts
> > > for the interface, I take this into account.
> I would say that adding new logis and especially rating them are also
> primary concerns. Especially one can't make rating easy enough if one
> wants users to actually do it (I also went at great lenghts to make
> this as easy as possible with OgOg, I think that if we replace the
> images with something loftier than skulls and stars we might actually
> use that code almost literally in Manta).
> > > 3. The logis are presented on the left side of the viewport, for ease of
> > > reading and simply beceause that area is one of the first focal points a
> > > user will look at, as has been indicated by several research projects in
> > > human computer interaction. Placing the logi on the left, and the sidebar on
> > > the right directs the user to the main content, which is the logi itself,
> > > and which is the primary use of logilogi.
> That's ok.
> (except for the problem stated further below, but there could be
> different solutions to that...)
> > > 4. The logis read as a book. Therefore, for titles and first-letter, a serif
> > > font is employed. For better legibility on screen, a sans-serif font is used
> > > for the main body of a logi, and paragraphs except the first after gaps are
> > > indented.
> This I like very much. Very clear, very alpha-friendly.
> > > 5. The header is utilized only for the logilogi logo, and a sort of
> > > main/general navigation bar. Those navigational elements are toplevel, that
> > > is: non contextual and generic. Also, one might notice that things like
> > > about, or contact info and the like, are not included in this bar as I
> > > consider them not to be part of the primary focus. Indeed, even this main
> > > navigation bar is not really considered as primary use: I think this is more
> > > like a sort of meta navigation, and hence, more secondary in use.
> I like the tabs, but not the logo. And to be honest I do think we
> really do need a requested-received bar again, because that provides a
> clear context for what section/context the user is working in.
> (but more about that below)
> So the tabs should become less high and move up one level, to show
> above the requested-received-bar...
> > > 6. Entering searches - as that is in fact what the users will be doing when
> > > requesting a logi - and suggestions and feedback as to what logi is actually
> > > shown, are performed in a panel under the header. The visitor perceives this
> > > panel as coming or in a way 'sliding' out of the header, which gives it a
> > > more sleek look. Specifically, as a list of suggestions is longer that those
> > > 80px the panel constitutes, that list does indeed slide out downward. The
> > > tags of the logi which is consequently chosen and shown, are presented as
> > > nice ovals, with the first one being the primary tag (should be in different
> > > color than in the screenshots).
> I like this, but then as a wizzard, as an extra for people to use when
> they want to create a new page, or when they want to find out what's
> already there in the system.
> But it should not replace the hierarchical structure of Manta, as the
> idea of "Philosophical name-spaces" is central to it. And this sense
> of whether someone is looking at Aristotle from a historical
> perspective or from a philosophical one, requires this hierarchy,
> especially when one want's links from history/aristotle to look for
> matches inside history first, and otherwise in the global namespace.
> Actually this system is so central to LogiLogi that without it, it
> would be mostly just another wiki that supports tagging.
> So how I would see this wizzard - and in this I follow quite closely
> what Bruno suggested - is that users can start typing a word in there,
> and then through Ajax a lookup for matching tags is done, for these
> tags we could then start showing the locations of logi's out of which
> the user can then pick one. Like:
> The user starts typing Aristotle.
> About half-way four suggested locations show up:
> And the user can then pick one...
> This will also make it less likely that someone adds a page or section
> that already exists but under a slightly different name...
> Alternatively a concept-lattice, or tag-cloud, or something like that
> could also be shown...
> > > 6. While the left hand side is for reading logis, the sidebar constitutes
> > > the remainder of logilogi's primary use: navigating logis and viewing
> > > contextual information about the current logi, or the current user.
> This is neat. A small tiny point could be that it might be better to
> show the titles of logi's instead of their authors, as that provides
> more semantic richness for the reader to pick.
> > > 7. The main focus of the sidebar should be showing related logis. Firstly,
> > > direct alternatives (having exact same tagset), then the siblings, which are
> > > in other ways tag-wise related to the current logi. Finally there is a list
> > > of logis which the current logi links to in the body text, and a list of
> > > logis which link to the current one.
> Ok. So yes, incoming links should be shown, outgoing are not really
> neccesary, but could be added maybe. Also to compromise between quick
> access and a non-cluttered screen we could also add only a few (or
> even none) and have the rest unfold with ajax if more/the box is
> > > 8. Reading comments is actually reading 'related logis', except that with
> > > logis that act as comments on the current one, the reader would like to
> > > preview a few lines of the commenting logi. This is done Gmail-way: with one
> > > action (read comments), fold the current logi, and show for each commenting
> > > logi a few sentences - preferably a paragraph - with the possibility of
> > > unfolding a certain logi to read the complete body.
> Showing a few lines is ok, unfolding the body is not that ok, as then
> the reader will miss the context of the comment. And ideally comments
> will not just be plunged below (ending up at pagename/comments), but
> will be written first and then linked with what they are commenting on.
> In this way one can prevent the problems of fragmentation that threads
> bring with them (comments only on some part, and discussions repeating
> themselves endlessly).
> That's also why we don't want a tree-structure in comments. With only
> one level, and each comment having it's own context again there will
> be more opportunity for graph- instead of tree-like discussions.
> > > Hmm... while writing this up, I'm getting some more insights in the
> > > matter...
> > >
> > > What about - navigating logis being the primary use - having a specific set
> > > of actions - vis a vis, metaphors - the visitor can 'do' with logis: for
> > > instance, we are reading a logi, which defines our *reading context*, and we
> > > would like to see commenting logis. We _zoom out_, and the commenting logis
> > > are presented. Then, we _fold_ the current logi, and _unfold_ a certain
> > > commenting logi which we find interesting. Then, we find another commenting
> > > logi interesting, so we unfold that one. But we are still in the context of
> > > our first 'current logi', so we need to _zoom in_ to this commenting logi.
> > > Now, the *reading context* changes. Another interesting thing would be to
> > > see directly if there is a (or are several) logi on which this one is a
> > > comment: _zoom out_ and preview the commented logi(s).
> An interesting idea it is, but *reading context* should include the
> requested and received urls, and other stuff like incoming links...
> We don't want tree-like discussions, we want a tree-like context-
> structure (that people will be able to relate to that of directories,
> and that allows name-spacing and dynamic resolving of stuff that could
> not be found, to prevent lots of dead-links, and to allow dynamic
> > > Why this idea? There are in essence two ways logis can be related to each
> > > other: via a concept lattice (alternatives, siblings, etc), and via direct
> > > relations as comments or by links in the body text. In a lattice notions of
> > > a hierarchy are quite difficult to grasp, as the hierarchy depends on the
> > > way the lattice is instantiated and as the hierarchy is always relative to
> > > which concept we begin with. So navigating this is solved by the sidebar
> > > navigation panel. This is - by the way - also the case with direct in-text
> > > links. But looking at comments, we see that these form a real treelike
> > > hierarchy. So why not visualize this notion? It could be very similar to a
> > > forum, except better presentation ;)
> > >
> > > Well, we will see. Just an idea.
> The problem with forum-trees is that they do not naturally allow
> what (for us betha's) in programming would be called multiple
> inheritance, and in the humanities is just the plain old citing of
> multiple papers...
> Maybe funny but *NO THREADS IN LOGILOGI p e r i o d* :)
> > > 9. Editing, viewing history, etc, is not a key focus, therefore, the toolbar
> > > to do these things are initially not shown in a full blown way. What is
> > > presented, is a bar with a low opacity level, that is, it's very grey,
> > > low-saturation, barely visible. On hover, the user will see the toolbar in
> > > it's full glory.
> Fully agree, and a really beautiful solution!
> > > 10. Further information on the logi, for example, it's rating, are also
> > > shown on demand.
> Rating is central, so it (and the rating) should be shown in all
> levels of UI-complexity...
> (Web-2.0 is about modeling the social side of things and rating is the
> bread and butter of this in Manta)
> > > 11. Further contextual information, like peer group and language preference,
> > > are in the sidebar. I've put them above the logi navigation, although I'm
> > > not sure about this placement. It might just sit in the way there.
> We could add an account-tab for this... But at least the peergroup
> that's currently used as a filter should be shown. Also the user-
> group should be shown when editing/creating a new one, so the user
> knows who will have rights on it...
> (and now a reply to myself)
> > Some short notes:
> > In general I like the simplicity of the UI, but I think we simply need the
> > space on both sides of the text, as sections (like History/) should be able
> > to have their own news and menu's, and the immediate display of Incoming links
> > seems important at least for orientation in the complex UI. Same for ratings.
> This problem still sits there, although at least the news could be
> shown blog-like for sections, and stuff like the local recent changes
> could be shown in the side-bar.
> The main problem remaining are menu's, and yes I really think they
> should be there, so people will have pointers to important locations
> when visiting manta, or when browsing a section.
> In the current version they proved - however crudely implemented there
> - to be indispensable for history-students to find their way around:
> (example: http://en.logilogi.org/RuG/GescH/BaC2)
> So if you could come up with a good place to stack them while still
> not losing the beauty of a 2-column layout I would be gratefull...
> > (Other things I will think about is whether or not to allow not-logged in
> > visitors to pick a peer-group as a temporary filter (currently we do, but
> > this layout does not), and how the LogiLogi-Network bar would fit in...)
> (first point already noted above)
> The LogiLogi network bar. Where/how ?
> > So a good UI, and some nifty ideas above, but more comments later,
> Still think at the core it is a good UI...
> Looking forward to the real HTML+CSS+JS, and to hearing what Bruno
> thinks of it.
> greetings :)
> PS: The skype conversation will be difficult as I appear not to have a
> working microphone where I am now... So we should stick to the list
> and to IRC maybe...
> > Wybo
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> LogiLogi-list mailing list