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

~ OgOg.org has gone international! ~

http://foundation.logilogi.org/2007/7/16/ogog-goes-international

It's available now in: Deutsch (http://de.ogog.org), English
(http://en.ogog.org), Español (http://es.ogog.org), 日本語
(http://ja.ogog.org), and Nederlands (http://nl.ogog.org).

Bruno if you would like to become OgOg ambassador for the Spanish
site, that would be great. And if anyone from the Nijmegen team 
would like to become ambassador for the Dutch site I'm willing to
step aside...

Also the UI was improved a bit, and memory-usage reduced... We are
still having a small memory-leak in OgOg though...

~ Bruno's Logo ~

> It's just a quick scratch, but it could get better.
> How do you all like it? ;)

I like it, but the font maybe could become Verdana. Also the L's
might be moved a bit closer to eachother...

Nice initiative!

> -- 
> Bruno

~ The Grant ~

Tomorrow I will be going to Amsterdam to have a take-in meeting
about our grant-proposal. It is not yet certain though that Manta
will receive the grant...

greetings,

Wybo

PS: I will now start working on Andrews tag-order today, and maybe
wednesday... On thursday however I will go on holiday, so I hope I
can finish it before I leave... And Andrew & Charl, when will your
code be ready ?

Hi,

I've just come to the idea of getting a LL html logo, so here is the
code I comed up to:

<div style="font-family: arial; position: relative; height: 9em; width: 7.5em;">
<div style="position:absolute; left: .1em; top: .5em; font-size: 5em;
color: #0000FF; line-height: .9em; background-color: #ccffff; padding:
.05em;">L</div>
<div style="position:absolute; left: 0.75em; top: .1em; font-size:
5em; color: #0000FF; line-height: .9em; background-color: #ccffcc;
padding: .05em;">L</div>
<div style="position:absolute; left: 1em; top: 8em; font-size: 1em;
color: #0000FF; line-height: 1em;">LogiLogi.org</div>
</div>

It's just a quick scratch, but it could get better.
How do you all like it? ;)

-- 
Bruno

On 7/9/07, Wybo Wiersma <wy...@lo...> wrote:

> > Apart from ideas, I would like to get more concrete on
>
> ...am I missing a part of the e-mail ? Such an abrubt end.
>

sorry about it, don't know what happened. I wanted to say that I
realized I need to get to some concrete work, get a objetive and start
coding, but I see we are still in transition, and I even don't have a
concrete proposal for the entire UI. We should get all the proposed
ideas/features, and all together decide what will be our
objective/proposal for next version of LL, estimate time, and get down
to work on it... (at least I would like to)

Wybo, what would you say about this?

> > > I will be visiting Amsterdam this weekend, and on sunday afternoon I
> > > will be meeting with a group of philosophers who are interested in
> > > LogiLogi...
> >
> > Great man! let us know how it went!
>
> It went well. We actually had quite interesting conversations. Also
> about what LogiLogi could mean for the world and for humanity... It's
> main advantages over normal conversations being it's memory and it's
> capability of functioning globally, across spatial and institutional
> borders.
>
> If - and that's the big IF - we succeed in getting many people to use
> LogiLogi, then we might be able to make possible a sharing, criticizing,
> extending, and refining of ideas of an intensity, with a precision and
> on a scale as never seen before. By initiating this global deliberation
> we can truely make a difference for the good of humanity. And our times
> overran by increasing social and conceptual complexity might very well
> be in need of such a change. Let it be our little revolution.
>
I share how you see/feel things. I also found that when I explain
logilogi to people who likes to argue, philosophy, they get very
interested right away. Then we have the gap between potential and real
limitations, like GUI, features, content/visitors... This limitations
are our current usability problem, and we should think of the next
version to solve this problems (we are already advancing in this
path).

> Wybo
>
> PS: The selection of the Digitale Pioniers projects that will receive
> their grants has not been made public yet, so it's uncertain still how
> we did. Also note that we applied for only a little less than 10k
> euro's as that will be enough for making Manta usable...
>

When will this be the results known? Digital Pioneers is a very
exiting project to promote projects! it's already great to be in the
top 20. (also, I couldn't find logilogi in the listings)


Greetings all
-- 
Bruno

I just committed Allan's code to the Gip-branch. Looks good, although
it will still require some work on our part to make it fully usable... 

Anyway I made a few minor cleanup changes (removed .*~ temporary edit-
files for example)... Once Andrews UI is here we can do the rest of 
the integration of the Editor...

> --- Charl
> In accordance with my personal "simplicity is key" motto, I would vote
> for option 2. I agree with Andrew about the sequence of tags (primary
> first). Also, regardless of the sequence of tags you choose in the
> end, it seems best that the display in the address bar is the same as
> that in the GUI view.
>
> --- Bruno
> I think Andrew's proposal has some advantages which I'd preferred. His
> proposed order also makes it easier to recognize for example
> "Foucault", and right there show the available options/suggestions. I
> see it is logical to give a try to the content tag first and then the
> context tags. I also see the context tags has an order, which I also
> see positive.

Great; Then we all agree! Let's make it official: We will be going for 
Andrews tag-order. Many thanks for your insight on this Andrew!

(For the record: more info in my previous post: http://sourceforge.net/mailarchive/forum.php?thread_name=20070704201750.GA30673%40logilogi.org&forum_name=logilogi-list)

> --- Bruno
> Tags are great!
> 
> I see the coloring you talk about as semantic over words (or set of
> words?), color, size, xhtml tag id, which would be all in parallel,
> from the core coding to the css styling.

Indeed, somewhat (if I correctly understand you).
 
> In this same path, I see we should be more flexible with tags, like
> being able to asign them properties. I don't understand much of the
> branching, complexity of queries, but I see tags should be associated
> with "tag-types", like tags being an object itself with properties. I
> also see that tags should be linked to the search of that tag
> (Foucault for example) or should be to a logi=id? We've talked about
> this before.

We are actually close to what you propose. Currently we have four 
tagging-types: 'content' (former primary), 'context' (former secondary), 'menu'
and 'news'. Where taggings are relationships between tags (former words)
and logi's (through logi-id's).

Tags are not stored in relation to queries. Queries are made up of
tags (but not stored)... Tags also cannot be tagged at the moment or
anything like that (for the sake of simplicity).

> What camed first, the tag or the logi? what are everyones thought
> about this? will we be able to walk this path or is it not possible at
> this moment?

In the logic that I see currently a logi cannot exist untagged, and
tags cannot exist without an associated logi/peer-/user-group.

> Also I've been thinking at something written before, about "zooming in
> and zooming out" like different levels, if we got logis as wybo
> proposes, short articles to describe something specific, and we
> request a content like a person name "Michel Foucault", you could see
> the first popup logi, but then "zoom out" and start seeing the most
> common information requested for that query (plus other tags) popping
> up, some kind of map...

It would be cool indeed to have a Java 2/3D interface one day, but
that - even planning it - is still far into the future with current
means...

> Apart from ideas, I would like to get more concrete on

...am I missing a part of the e-mail ? Such an abrubt end.

> > I will be visiting Amsterdam this weekend, and on sunday afternoon I
> > will be meeting with a group of philosophers who are interested in
> > LogiLogi...
> 
> Great man! let us know how it went!

It went well. We actually had quite interesting conversations. Also
about what LogiLogi could mean for the world and for humanity... It's
main advantages over normal conversations being it's memory and it's 
capability of functioning globally, across spatial and institutional
borders.

If - and that's the big IF - we succeed in getting many people to use
LogiLogi, then we might be able to make possible a sharing, criticizing,
extending, and refining of ideas of an intensity, with a precision and
on a scale as never seen before. By initiating this global deliberation
we can truely make a difference for the good of humanity. And our times
overran by increasing social and conceptual complexity might very well 
be in need of such a change. Let it be our little revolution.

Wybo

PS: The selection of the Digitale Pioniers projects that will receive
their grants has not been made public yet, so it's uncertain still how
we did. Also note that we applied for only a little less than 10k 
euro's as that will be enough for making Manta usable...

On 7/6/07, Wybo Wiersma <wy...@lo...> wrote:
> I will be visiting Amsterdam this weekend, and on sunday afternoon I
> will be meeting with a group of philosophers who are interested in
> LogiLogi...

Great man! let us know how it went!

>
> Today I have been working on making OgOg a bit faster, and I've been
> adding gettext, for translation... The OgOg re-launch (OgOg is down
> due to server overload) will probably be around the beginning of next
> week...
>
> greetings,
> and looking forward to the mockup of Andrew :),
>
> Wybo
>
> PS: Charl first of all many thanks for your code! I have not yet
> reviewed it awaiting your commit. If it is not committed by monday,
> I will do it for you, and then review it...
>
> -------------------------------------------------------------------------
> 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.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> LogiLogi-list mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/logilogi-list
>


-- 
Bruno

On 7/4/07, Wybo Wiersma <wy...@lo...> wrote:
> Today at the presentation given by the Gip/Nijmegen-team Andrew and I
> discussed the order of tags within links (in response to his new
> mockup, which he will show us soon, I guess...).
>
> The question is: What anology, search, or a dir-structure...
>
> ~ The current order of tags is modelled after a directory-structure: ~
>
> A typical LL-url would be:
>
> GroningenUniversity/History/Foucault
>
> Where the tags are of type:
>
> Context 1 / Context 2 / Content
>
> When it's being resolved and not all tags can be found the following
> sets of links are tried:
>
> GroningenUniversity/History/Foucault
> GroningenUniversity/Foucault
> Foucault
>
> (also see
> http://www.logilogi.org/pub/mantadocs/app/classes/Link.html#M000202)
>
> Logi-links (links to a specific Logi) are constructed as in this
> scheme:
>
> GroningenUniversity/History/Foucault=<logi_id>
>
> And when browsing GroningenUniversity/History/Foucault one would see
> the menu assocated with History (the menu-logi would be tagged with
> History as type menu, and have GroningenUniversity as a context-tag).
>
> ~ The order of the proposals of Andrew is modelled after a query: ~
>
> A typical query would be:
>
> Foucault, History, GroningenUniversity
>
> Where the tags are of type:
>
> Content, Context 1, Context 2
>
> And on resolving the tried out sets would be:
>
> Foucault, History, GroningenUniversity
> Foucault, History
> Foucault
>
> (Fairly superior in simplicity!)
>
> Logi-links would then - to stick with the logic - be something like
> this:
>
> <logi_id>=Foucault,History,GroningenUniversity
>
> A bit les logical, and surely counter-intuitive in the url-bar of the
> browser, but the advantage would be that logi-links could become plain
> and simple permalinks, by leaving out the tags, which would then be
> added as received tags (from the main_link associated with the logi):
>
> <logi_id>
>
> Menu's and news and such could become a bit counter-intuitive, but
> this could be fixed by showing the tag with which the menu is
> associated also in a different color than the other context-tags.
>
> Something like
>
> (Foucault) <History> GroningenUniversity
>
> (where the ()'s and <>'s stand for different colors, probably the <>'s
> matching the color of the menu...)
>
> If History would not have a menu, but GroningenUniversity would, then
> it would show as
>
> (Foucault) History <GroningenUniversity>
>
> ~ The choice... ~
>
> The options:
> 1) Dir-structure for both urls and query's
> 2) Query-structure for both urls and query's
> 3) Query-structure for queries (the wizzard and the requested-received-
>    listing) and a dir-structure for urls...
>
> I see them both as having some merits and some problems.
>
> Actually I am slightly leaning towards option 2, and I am at least
> interested in trying option 3 (for the UI), especially as it will also
> fit in nicely with the wizzard that is part of UI-proposal.
>
> What are the opinions of others on this ?
>

~ my opinions:

I think Andrew's proposal has some advantages which I'd preferred. His
proposed order also makes it easier to recognize for example
"Foucault", and right there show the available options/suggestions. I
see it is logical to give a try to the content tag first and then the
context tags. I also see the context tags has an order, which I also
see positive.

Tags are great!

I see the coloring you talk about as semantic over words (or set of
words?), color, size, xhtml tag id, which would be all in parallel,
from the core coding to the css styling.

In this same path, I see we should be more flexible with tags, like
being able to asign them properties. I don't understand much of the
branching, complexity of queries, but I see tags should be associated
with "tag-types", like tags being an object itself with properties. I
also see that tags should be linked to the search of that tag
(Foucault for example) or should be to a logi=id? We've talked about
this before.

What camed first, the tag or the logi? what are everyones thought
about this? will we be able to walk this path or is it not possible at
this moment?

Also I've been thinking at something written before, about "zooming in
and zooming out" like different levels, if we got logis as wybo
proposes, short articles to describe something specific, and we
request a content like a person name "Michel Foucault", you could see
the first popup logi, but then "zoom out" and start seeing the most
common information requested for that query (plus other tags) popping
up, some kind of map...

> (I see that it could be a problem to have 2 different orders of tags
> at the same time...)
>
> Wybo

Both are very good/simple/concrete descriptions of both methods, and
we should have some similar explanations for the future (whichever it
is) version.

Apart from ideas, I would like to get more concrete on

-- 
Bruno

I will be visiting Amsterdam this weekend, and on sunday afternoon I
will be meeting with a group of philosophers who are interested in
LogiLogi...

Today I have been working on making OgOg a bit faster, and I've been
adding gettext, for translation... The OgOg re-launch (OgOg is down
due to server overload) will probably be around the beginning of next
week...

greetings,
and looking forward to the mockup of Andrew :),

Wybo

PS: Charl first of all many thanks for your code! I have not yet
reviewed it awaiting your commit. If it is not committed by monday, 
I will do it for you, and then review it...

> Hello,
> 
> I've added  my code to the giplogi branch at sourceforge but here
> are the most important files I modified, for convenience.

I saw no commit-message... and the branch seems still un-changed. You
should run svn commit inside the branch-dir for submitting it.

Ofcourse I could also commit it in your place, but it would be better
(also for the credits of who did what) if you committed it yourself
(and you do have commit-rights...).

> Wybo, I wish you luck in trying to obtain the 'digital pioniers' grant.

Thanks,

Wybo

> Best regards,
> 
> Allan

Hello everyone,

In accordance with my personal "simplicity is key" motto, I would vote
for option 2. I agree with Andrew about the sequence of tags (primary
first). Also, regardless of the sequence of tags you choose in the
end, it seems best that the display in the address bar is the same as
that in the GUI view.

Regards,
Charl


On 7/4/07, Wybo Wiersma <wy...@lo...> wrote:
> Today at the presentation given by the Gip/Nijmegen-team Andrew and I
> discussed the order of tags within links (in response to his new
> mockup, which he will show us soon, I guess...).
>
> The question is: What anology, search, or a dir-structure...
>
> ~ The current order of tags is modelled after a directory-structure: ~
>
> A typical LL-url would be:
>
> GroningenUniversity/History/Foucault
>
> Where the tags are of type:
>
> Context 1 / Context 2 / Content
>
> When it's being resolved and not all tags can be found the following
> sets of links are tried:
>
> GroningenUniversity/History/Foucault
> GroningenUniversity/Foucault
> Foucault
>
> (also see
> http://www.logilogi.org/pub/mantadocs/app/classes/Link.html#M000202)
>
> Logi-links (links to a specific Logi) are constructed as in this
> scheme:
>
> GroningenUniversity/History/Foucault=<logi_id>
>
> And when browsing GroningenUniversity/History/Foucault one would see
> the menu assocated with History (the menu-logi would be tagged with
> History as type menu, and have GroningenUniversity as a context-tag).
>
> ~ The order of the proposals of Andrew is modelled after a query: ~
>
> A typical query would be:
>
> Foucault, History, GroningenUniversity
>
> Where the tags are of type:
>
> Content, Context 1, Context 2
>
> And on resolving the tried out sets would be:
>
> Foucault, History, GroningenUniversity
> Foucault, History
> Foucault
>
> (Fairly superior in simplicity!)
>
> Logi-links would then - to stick with the logic - be something like
> this:
>
> <logi_id>=Foucault,History,GroningenUniversity
>
> A bit les logical, and surely counter-intuitive in the url-bar of the
> browser, but the advantage would be that logi-links could become plain
> and simple permalinks, by leaving out the tags, which would then be
> added as received tags (from the main_link associated with the logi):
>
> <logi_id>
>
> Menu's and news and such could become a bit counter-intuitive, but
> this could be fixed by showing the tag with which the menu is
> associated also in a different color than the other context-tags.
>
> Something like
>
> (Foucault) <History> GroningenUniversity
>
> (where the ()'s and <>'s stand for different colors, probably the <>'s
> matching the color of the menu...)
>
> If History would not have a menu, but GroningenUniversity would, then
> it would show as
>
> (Foucault) History <GroningenUniversity>
>
> ~ The choice... ~
>
> The options:
> 1) Dir-structure for both urls and query's
> 2) Query-structure for both urls and query's
> 3) Query-structure for queries (the wizzard and the requested-received-
>    listing) and a dir-structure for urls...
>
> I see them both as having some merits and some problems.
>
> Actually I am slightly leaning towards option 2, and I am at least
> interested in trying option 3 (for the UI), especially as it will also
> fit in nicely with the wizzard that is part of UI-proposal.
>
> What are the opinions of others on this ?
>
> (I see that it could be a problem to have 2 different orders of tags
> at the same time...)
>
> 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.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> LogiLogi-list mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/logilogi-list
>

Hello,

I've added  my code to the giplogi branch at sourceforge but here are the most important files I modified, for convenience.

Wybo, I wish you luck in trying to obtain the 'digital pioniers' grant.

Best regards,

Allan

Today at the presentation given by the Gip/Nijmegen-team Andrew and I
discussed the order of tags within links (in response to his new
mockup, which he will show us soon, I guess...).

The question is: What anology, search, or a dir-structure...

~ The current order of tags is modelled after a directory-structure: ~

A typical LL-url would be:

GroningenUniversity/History/Foucault

Where the tags are of type:

Context 1 / Context 2 / Content

When it's being resolved and not all tags can be found the following
sets of links are tried:

GroningenUniversity/History/Foucault
GroningenUniversity/Foucault
Foucault

(also see
http://www.logilogi.org/pub/mantadocs/app/classes/Link.html#M000202)

Logi-links (links to a specific Logi) are constructed as in this
scheme:

GroningenUniversity/History/Foucault=<logi_id>

And when browsing GroningenUniversity/History/Foucault one would see 
the menu assocated with History (the menu-logi would be tagged with 
History as type menu, and have GroningenUniversity as a context-tag).

~ The order of the proposals of Andrew is modelled after a query: ~

A typical query would be:

Foucault, History, GroningenUniversity

Where the tags are of type:

Content, Context 1, Context 2

And on resolving the tried out sets would be:

Foucault, History, GroningenUniversity
Foucault, History
Foucault

(Fairly superior in simplicity!)

Logi-links would then - to stick with the logic - be something like
this:

<logi_id>=Foucault,History,GroningenUniversity

A bit les logical, and surely counter-intuitive in the url-bar of the
browser, but the advantage would be that logi-links could become plain
and simple permalinks, by leaving out the tags, which would then be
added as received tags (from the main_link associated with the logi):

<logi_id>

Menu's and news and such could become a bit counter-intuitive, but
this could be fixed by showing the tag with which the menu is
associated also in a different color than the other context-tags.

Something like

(Foucault) <History> GroningenUniversity

(where the ()'s and <>'s stand for different colors, probably the <>'s
matching the color of the menu...)

If History would not have a menu, but GroningenUniversity would, then
it would show as

(Foucault) History <GroningenUniversity>

~ The choice... ~

The options:
1) Dir-structure for both urls and query's
2) Query-structure for both urls and query's
3) Query-structure for queries (the wizzard and the requested-received-
   listing) and a dir-structure for urls...

I see them both as having some merits and some problems.

Actually I am slightly leaning towards option 2, and I am at least
interested in trying option 3 (for the UI), especially as it will also
fit in nicely with the wizzard that is part of UI-proposal.

What are the opinions of others on this ?

(I see that it could be a problem to have 2 different orders of tags
at the same time...)

Wybo

I just finished, and submitted the movie for the Digitale Pioniers. 
We had only 90 seconds, so hardly anything could be shown in that
time, and while I first had quite a lengthy piece planned about the
Gip-team, I had to drop it in order to tell the bare minimum about
Manta and it's prospect users...

Sadly enough I just missed Bruno in the IRC, and the Youtube movies
didn't convert to AVI, so they cannot see Bruno on video, but many
thanks anyway for your late-night attempts to fix it...!!

It has been a long two days of filming and especially editing. I had
to learn a lot, and probably there are still many problems with the
quality of the movie, but so be it - the deadline hit...

Also many thanks to my sister Femke - who is an AV-student - for
helping me with the filming (she's not that much into computers 
besides somewhat as tools for editing :)

The movie can be dowloaded here, for those interested, it is in Dutch 
though, as the expert-panel (that will judge about the projects on
wednesday) is Dutch too...:

Divx AVI (17mb):
http://www.logilogi.org/pub/LogiLogiMantaVoorDeDigitalePioniers.avi

Quicktime (26mb):
http://www.logilogi.org/pub/LogiLogiMantaVoorDeDigitalePioniers.mov

greetings,

Wybo

I integrated the version without senses into the trunk today and the
branch called senseless has now been deleted.

Also within the code I renamed branches (not the svn-kind of branch,
but the navigational kind in the current pre-alpha: primary/content
tags of logi's that have the received tags as secondary/context tags)
to offspring (will normally be branching off further from the tree),
and stems (secondary/context- tags that one can use to further specify
the context...) to contextualizations...

If one visit's foucault 'history' would show up as a contextualization,
that would show one only logis about foucault from the history-
perspective, and if one visits history, foucault would show up as
offspring...

We could discuss this and change it again, but it seemed a bit less
unintuitive to me to call them this... :) Though still not perfect...

greetings,
and looking forward to the UI-mockup :),

Wybo

> Hi,
> 
> Might I suggest using the GPLv3 comment system or a similar system to
> link comments to specific paragraphs? Each part of the document would
> then have its own _single_ thread (no tree structure). The "parts" are
> defined entirely by the user: if a user wishes to comment on a larger
> section, he can simply do so.
> 
> http://gplv3.fsf.org/comment/agplv3-draft-1.html#3292:

I really would like to have that in LL, but then a bit different, in
such a way that it would allow one to add links by just selecting a
snippet of text, and then adding an url to another logi in a popup-
box (and we could show a snippet of the linked logi, as we could do
now too in the link-drop-down box).

Possibly one could be able to enter the logi-text in there too, but we
should be carefull with that in order to prevent hasty, threaded 
comments that duplicate things already remarked by others (possibly in
reply to different texts)...

What we could consider however is also adding comments as a separate
class, and reserve them for the more emotional/motivational kind of
replies, and keep logi's for the more in-depth stuff. So then comments
at the bottom would be this restricted kind (possibly with a very
short maximum length), and then the "paragraph-related"/linked out
comments would be other logi's stored at another LL-link-location.

Actually I bet that in the background, in terms of the position-ranges
associated with links, and storing links separately from the text,
their system is quite comparable to that part of manta...

Wybo

> Kind regards,
> Charl

Hey Charls, just a minute ago I've posted a short reply. I have to go
to bed now.

Also, the GPLv3 commenting system is exelent, we've already talked
about this, and it would also be great to get something like this to
LL...

Later man!

On 6/30/07, Charl <ch...@tu...> wrote:
> Hi,
>
> Might I suggest using the GPLv3 comment system or a similar system to
> link comments to specific paragraphs? Each part of the document would
> then have its own _single_ thread (no tree structure). The "parts" are
> defined entirely by the user: if a user wishes to comment on a larger
> section, he can simply do so.
>
> http://gplv3.fsf.org/comment/agplv3-draft-1.html#3292:
>
> Kind regards,
> Charl
>
>
> On 6/30/07, Wybo Wiersma <wy...@lo...> wrote:
> > Andrew (as tales) and I (as wyb1) had quite an interesting
> > conversation this evening on IRC in which mutch of the disagreement
> > has been put away, and much agreement and understanding has been
> > gained... If anyone wants to read it, here are the logs:
> >
> > http://www.openideaproject.org/irclogs/browse/logilogi/2007/06/29
> >
> > Andrew will also be adding some of it to the wiki, and he will show
> > us his updated mockup tomorrow...
> >
> > A good night to all :)
> >
> > (and remember the video's for sunday)
> >
> > 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.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > LogiLogi-list mailing list
> > Log...@li...
> > https://lists.sourceforge.net/lists/listinfo/logilogi-list
> >
>
> -------------------------------------------------------------------------
> 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.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> LogiLogi-list mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/logilogi-list
>


-- 
Bruno

Hi all,

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
great project!

Later.

On 6/29/07, Wybo Wiersma <wy...@lo...> 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:
>
> Aristotle
> history/aristocracy
> history/Aristotle
> philosophy/Aristotle
>
> 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
> clicked.
>
> > > 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
> growth...).
>
> > > 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 :)
>
> Wybo
>
> 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.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> LogiLogi-list mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/logilogi-list
>


-- 
Bruno

Hi,

Might I suggest using the GPLv3 comment system or a similar system to
link comments to specific paragraphs? Each part of the document would
then have its own _single_ thread (no tree structure). The "parts" are
defined entirely by the user: if a user wishes to comment on a larger
section, he can simply do so.

http://gplv3.fsf.org/comment/agplv3-draft-1.html#3292:

Kind regards,
Charl


On 6/30/07, Wybo Wiersma <wy...@lo...> wrote:
> Andrew (as tales) and I (as wyb1) had quite an interesting
> conversation this evening on IRC in which mutch of the disagreement
> has been put away, and much agreement and understanding has been
> gained... If anyone wants to read it, here are the logs:
>
> http://www.openideaproject.org/irclogs/browse/logilogi/2007/06/29
>
> Andrew will also be adding some of it to the wiki, and he will show
> us his updated mockup tomorrow...
>
> A good night to all :)
>
> (and remember the video's for sunday)
>
> 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.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> LogiLogi-list mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/logilogi-list
>

Andrew (as tales) and I (as wyb1) had quite an interesting
conversation this evening on IRC in which mutch of the disagreement
has been put away, and much agreement and understanding has been
gained... If anyone wants to read it, here are the logs:

http://www.openideaproject.org/irclogs/browse/logilogi/2007/06/29

Andrew will also be adding some of it to the wiki, and he will show
us his updated mockup tomorrow...

A good night to all :)

(and remember the video's for sunday)

Wybo

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:

Aristotle
history/aristocracy
history/Aristotle
philosophy/Aristotle

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 
clicked.

> > 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
growth...).

> > 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 :)

Wybo

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

I just committed the final fixes for the sense-removal. I will
integrate it with the main-branch this weekend (without taking
the current demo offline)...

Quite some things have been simplified and improved.

LinkParts as separate database-entries are now gone, they are
now embedded in the links as link_parts_strings. LinkTags 
partially replaced them for purposes of Tag-bookkeeping and
finding incoming links....

Among other things Manta became a bit more hierarchical. 
From-links have now been replaced... by a main_link on the 
Logi. So no matter in what context a logi is edited, links
will be shown as coming from the main_link of the logi...

Another change is that elements are now kinds of taggings,
just like content (former primary) and context (former 
secondary) taggings. They can be accessed now through:
links like LogiLogi/manta~menu. Where the tilde separates
the tag from the kind.

Some other minor changes were made...

And last but not least, of course senses have been removed
now. The one thing missing are tests and some code for the 
deleting/destroying of stuff, but lets build up first :)

This version has no working UI yet, so you can't test it or
thinker with it through anything but the script/console of
rails at the moment...

The svn is here (untill integrated in the trunk):
https://logilogi.svn.sourceforge.net/svnroot/logilogi/branches/senseless

greetings,
(and tomorrow evening more about the UI)

Wybo

I just received an e-mail of Andrew that his e-mails did not arrive due to the
IP of his student-house being marked as a source of spam. So I am forwarding
them for him to the LogiLogi-list. Andrew I also signed you up with your gmail
account, so you can follow the discussion, and participate...

I put the screenshots that were attached on the wiki:

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...

---

(In Dutch about the screenshots being attached, and besides images also html+
css already existing...)

> 1. De screenshots van de mockups. Zijn nu bijgevoegd. Een html+js+css pakket
> heb ik ook, daar heb ik al wat aardige interactie ingebouwd. Overigens ben
> ik nog niet helemaal uit over het kleurenschema. Hieronder volgt een
> copypaste uit het mailtje:
> 
> "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.
> 
> I'm still trying to improve this design, so it will definitely not be the
> final outcome of our little UI project."

(Note in Dutch about it already being integrated in a local working-copy
of Manta. Also it does not work fully yet in IE)

> 2. Ondertussen is integratie in logilogi (mijn working copy) bijna rond.
> Hopelijk kan ik je eea laten zien. Ik heb vooral problemen het zaakje goed
> te krijgen voor Internet Explorer, dus wellicht moeten we dat maar even
> tijdelijk uitstellen.

(Note about his work on a logo containing a Manta)

> 3. Ik ben bezig met een logo voor logilogi manta, gebaseerd op een heuse
> manta. Die zie je ook in wazige vorm linksboven in de screenshots. Ik ben
> nog niet helemaal over de kleuren e.d. uit. Ik wil het graag zo simpel
> mogelijk houden, en toch grote uitdrukkingskracht laten hebben.

(A color-scheme is also attached, I added it to the Wiki too)

> 4. Kleurenschema: bijgevoegd is een html met een aantal kleurenschemas.
> Ikzelf neig erg richting dit soort 'muted' colors.
> 
> Nu dan reactie op jou en Bruno's mail over de UI.

(His reaction to the mail of me and Bruno)

> --
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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).
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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).
> 
> 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.
> 
> 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.
> 
> 10. Further information on the logi, for example, it's rating, are also
> shown on demand.
> 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.
> 
> Anyway, this concludes my short enumeration of interface highlights.
> 
> --

(Proposal to open a wiki-page for this discussion)

> Volgens mij kan ik dit niet naar de logilogi lijst sturen, omdat dit
> emailadres niet lid is. Zou jij mijn engelse delen willen forwarden?
> Misschien moeten we maar wat wiki pagina's openen hierover, want het begint
> toch best 'diep' te worden allemaal.

(There are people currently trying out this UI as part of a small usabillity
test...)

> Voorts kan ik trouwens nog melden dat er nu wat mensen naar onze versie van
> de interface kijken. Van het weekend hoor ik er meer van.

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.

Another thing is that Manta is the name of the code, not of the site...

(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...)

So a good UI, and some nifty ideas above, but more comments later,

Wybo

The title should have been UI or the like...

> > I'm also emailing you just as a draft. I'd like to know your opinion
> > and after having it a little more advanced, publish it to the wiki.
> 
> Ok :),
> 
> Wybo

We took this conversation between Wybo and Bruno to the list.

(also I am interested in hearing from Andrew of the gip-team what he did...
apparently he has mockups already ?)

---

> I've been (as usually) thinking about the LL UI, and I still have an
> ideal of what it should be in my mind, and I'm taking it down to
> reality with time... I'm writing down a full explanation/justification
> of the idea.
>
> In short (ok, not so short):
>
> When communicating, language is always the channel and it's also what
> limits what we can communicate, which is never pure perfect. The UI is
> language too, and not only when something is written down, but also
> with simbols. I've written some more extended about this, but you get
> the idea.

I get it, and fully agree...

> Then, when I have to think of a user that get's to LL, from which we
> don't know certainly many information (apart from guessing lang from
> country and browser) I think we should reduce the interface to the
> most universal language we can, and make it as simple as possible, and
> from there on, give the user the posibility to add more components to
> the interface and start customizing the interface from the information
> we get from the user.

It could be confusing for the user (some work to implement) to add
functionality to the interface in a modular way. Then many people
would see a somewhat different interface. It might be better to have
like 3 different levels of complexity for the interface...:

Like: Beginner, Normal, Pro

> Also, LL is a UI inside other UI, which we know in most cases will be
> a web browser, and a web browser which has a URL bar in which the user
> typed to get to LL (if not a link). We should take this in count as,
> right now, we might be creating a confusion when presenting the
> requested information "again" in the page body. Going back to the

This is true (the reason for it was that it's easier to compare them
when they are shown just above eachother..., and another that most
users don't even look at the url-bar of their browser normally...)

But you have a point...

> language problem, what I see in rough, is a minimal initial interface
> that would show little information (very little) and will let the user
> tell logilogi what he is looking for, and the system will return it's
> best guess, or a list of options to choose from. The Nijmegen students
> already proposed (for what I undertsood) a suggested links list. The
> most universal interface to ask a user to imput information would be a
> input field. This interface in conjunction with web2.0 instant
> suggestions would take a shortcut between the user and LL. We could
> adapt the information presented to the user just with some characters
> typed, presenting suggestions to complete a word at first (for
> example), and from then suggesting logis related to the rest of
> contextual information we already have (current date time, ip-country,
> browser lang, referal website, etc). All this could be done with just
> a couple of typed characters, which will start asking the user to
> define bethween options, which will define his path through the whole
> LL experience.

This is a very interesting idea.

(one thing is however that users like to browse too, so to see things
that are there already, that define context, and that they can click
on)

> I imagine it as simple as it can get. Just present the user with the
> information he already knows (or should know) he requested, but in a
> fully exposed manner. I'll make a draft of the interface, but in this
> case I went the other way round and started from the justification of
> a concept and then I'll draw it, which will actually not have much of
> drawing, and more of concept.

I am looking forward to it.

> Also the idea is to make the user choose from options, which will lead
> him to things he requested and there wont be much items to ask where
> they came from.
>
> I have a more extended text writen wich I could share with you, but
> basically its what I've wrote but extended. I still have to think of
> the idea in a whole.

Indeed. If you like, I would like to read it.

> Changing subject, about the personal point of view of OgOg I've talked
> to you yesterday... What I feel I'd like to be able to do, is to have
> as default rating option as it is right now, but instead of making the
> vote from a Overall point of view, take it more personal, and take it
> as a personal vote, which would represent how you liked it, but not
> from a Overall point of view which will influence the Overall POV to
> the public, but from a personal point of view that will weight only to
> the displayed data to me. I will think further about this as it's not
> a fully developed idea, but... I'm trying to publis earlier...

This would then more be like bookmarking than voting ?

And what would new users see ?

> I'm also emailing you just as a draft. I'd like to know your opinion
> and after having it a little more advanced, publish it to the wiki.

Ok :),

Wybo

Thanks Charles, and Miguel, and Bruno for your positive words!

> Fantastic news!
>
> Wybo, I will make a video if you think that this would help, please tell me
> when you will need it.

We need to send out the final video on monday, so if your, and Bruno's part are
e-mailed to me before sunday evening, it should be fine.

(online somewhere, or as an attachment if < 10mb)

Wybo :)

> The best for all the LL-team!
>
> Miguel

Fantastic news!


Wybo, I will make a video if you think that this would help, please tell me
when you will need it.


The best for all the LL-team!

Miguel



On 6/27/07, Bruno Sarlo <bru...@gm...> wrote:
>
> Thanks for those words!!!
>
> Thanks you for shearing with all your knowledge and I hope we get to
> work further together!!!   My whole experience with logilogi has been
> open-minding, and from the very beginning, and now so many more heads
> thinking together how to get a better LL, and specially in the UI, it
> all has been very enriching, and getting better...
>
> On 6/27/07, Charl <ch...@tu...> wrote:
> > Dear Wybo and other LogiDevelopers,
> >
> > On behalf of the GIP-team, I would like to congratulate you with
> > having come so far with LogiLogi already.
> > >From the Digitale Pioniers website:
> > "Per ronde [round] is ongeveer [approx] euro 125.000 beschikbaar om
> > aan projecten toe te kennen. Gemiddeld [average] ontvangen
> > gehonoreerde projecten euro 17.000."
> > This leaves room for about 7 projects to be awared this (staggering)
> > amount of money. For LogiLogi, this would certainly be the final push
> > to create a sublime product from a wonderful idea. And, of course,
> > even without the money, the system will thrive in today's web. Us from
> > GIP are proud to have contributed to this project. Wybo, Bruno, and
> > all others who have LogiLogi close to their heart, all the best!
> >
> > Kind regards,
> > Charl
> >
> >
> > On 6/27/07, Bruno Sarlo <bru...@gm...> wrote:
> > > Ok, I'll give it a try!
> > >
> > >
> > > On 6/27/07, Wybo Wiersma <wy...@lo...> wrote:
> > > > > Wow! Really great news!! congratulations to all!
> > > > >
> > > > > Wybo, you already got used to the cameras... (fosdem) jeje...
> > > > >
> > > > > If I find the words, I might get to record something, but I doubt
> it...
> > > >
> > > > Just something like: Hi, I am Bruno Sarlo, a developer of Manta, and
> I
> > > > work on the user interface, or something like that, would make it a
> > > > nice video...
> > > >
> > > > Wybo
> > > >
> > > > > Great news!!!
> > > >
> > > > ------------------------------------------------------------
> -------------
> > > > 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.
> > > > http://sourceforge.net/powerbar/db2/
> > > > _______________________________________________
> > > > LogiLogi-list mailing list
> > > > Log...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/logilogi-list
> > > >
> > >
> > >
> > > --
> > > Bruno
> > >
> > > ------------------------------------------------------------
> -------------
> > > 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.
> > > http://sourceforge.net/powerbar/db2/
> > > _______________________________________________
> > > LogiLogi-list mailing list
> > > Log...@li...
> > > https://lists.sourceforge.net/lists/listinfo/logilogi-list
> > >
> >
> > ------------------------------------------------------------
> -------------
> > 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.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > LogiLogi-list mailing list
> > Log...@li...
> > https://lists.sourceforge.net/lists/listinfo/logilogi-list
> >
>
>
> --
> Bruno
>
> -------------------------------------------------------------------------
> 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.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> LogiLogi-list mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/logilogi-list
>



-- 
Miguel Lezama