Re: [LogiLogi-list] The Big Mail

I decided to already post it even with the TODO's included. I will
reply to the TODO's/do the TODO's while in Leeds & when I'm back.

I will be back on the 13th.

Wybo

---

Hereby the long mail, a reply to many previous mails which I still did
not reply fully to. I'm typing this during some off moments while
staying with 40 pplz in a rented scouting-building + campsite.

I replied to most parts, but also left out some small bits responded
to elsewhere in the mail, and such.

> = Stallman
> It's great you got to talk to Stallman, although it was to know he has
> different view. Does he thinks LL's view and activism not good?

He said something about my hearth being in the right place, but in
general he saw Web-freedom as a lesser freedom.

> I also would like to know what he said about LL itself, as a project,
> did he liked it?

He couldn't use it as he does not use a web-browser as far as I've
heard/experienced. He seems to use wget to fetch his web-pages. So 
web2.0 apps stand no chanche with him.

> = Roadmap
> I believe we should all together trace the next-steps and road map in
> detail. For example, I strongly believe we have to make a stop, and
> rethink some aspects of LL and work over them before continuing to
> further development of the API, which would be the greatest expansion.

I agree we should rethink, but things should fit in with splitting it
up into separate services.

> = Democratization of development
> One of the future plans traced by Wybo was to include some democratic
> process in the development, which I think is great, and this also
> triggers lot's of other stuff that I've been thinking off for some
> time. Also this remembers me of leparlement, which is a fast way of
> searching democratic consensus :)

TODO demo

> == Developing over LL.org
> I've proposed this before, and some people had suggested the same
> thing after my talk, and I think now we are ready to start walking
> this way. We should get LL development to logilogi.org, and start
> using our own tool for LL's own development, in the end, we are always
> debating/exchanging ideas over the list/irc.

Upto some point this is a good idea. Especially for the more
philosophical & theoretical things we're discussing now. But the list
will nevertheless have it's uses, especially for things that are more
temporal like reporting on development, welcoming pplz, and stuff like
that.

> = Tags
> This is a returning topic. We currently have two big issues with tags:
> 
> == Query Vs. Dir structure
> This was brought back in my last large-mail about the new UI proposal
> [0] in the section "Navigation bar - too many tags". Basically, I
> tihnk we should opt for one way or the other but both the same, in the
> url and search bar and I believe the Query to be the most intuitive
> one.

This is, I think something about which I think that it is quite
central to LogiLogi TODO

> == Logi-lists
> I introduce this idea first in order to use for my next proposal for
> internationalization.
> 
> Logi lists are just what we have right now at the laguage settings
> plus going further and mixing lists across users/peergroups. This way,

Lists of contenders you mean I understood here from the chat.

To clarify; currently these are 2 different criteria. It first looks
for logis in your preferred languages, in order (if not in english,
then in dutch, etc), and then if it finds more than one, the ratings
are used to decide between those.

Here I used the principle of separating dimensions (TODO MAKE logi)

> the order would be a rating and thus we could apply an algorithm like
> the logis ranking does. This would be just one of the many ways there
> is for voting/ranking lists.
> 
> == Internationalization of tags
> We should pay attention to this. Right now it is a bit confusing since
> tags have no language. We talk about this before. There is no easy
> solution and we should discuss how to solve this. I would guess Wybo
> already has this in mind, what is your view on this?

To be honest my idea on this is to put this problem in the fridge for
now, and then when we take it out again, a solution like changing tags
to concepts again, and then allowing the association of words with
those, but keep it simple and allow every word only once.

That might circumvent the over-complex auto-resolve stuff we had
before for dealing with words with multiple meanings.

We will be able to auto-set defaults for tag-languages by looking at
the languages of most logis tagged with them.

> Here are my thoughts:
> 
> LL tags should be sorted and filtered, and should have some properties
> like language. I think for this we should apply some concepts we
> already use for logis mixed with list sorting as a way of voting. This
> would be:
> 
>  * I can rearrange the tags by dragging them which is a vote (a set of tags)
>  * the peergroups and power/weight applies for the rankings
>  * tags are displayed in many languages at the same time, as far as
> they are in my lang list at settings. (language list should show the
> option to chose which langs and not only sorting)
>  * how many tags are displayed can be determined (initially by
> default) to some amount of power at least
> 
> the functions should be thought still, but I want to show the idea.
> 
> This could be an example:
> 
> Content: Free, Libre, Livre ... (more tags)
> Context: Software, Codigo, Open Source, Linux
> 
> This way we are freeing up tags and still have them under control.
> Right now tags are freely editable at LL, but somehow not handy and
> adding, sorting and filtering (by language and amount) empowers them.
> Also about languages, for me is the same to have a tag in english or
> spanish, so I want to have both displayed. For the logi is different
> right now as we can not show more than one logi (for each spoken
> language), so we have to chose which to show. We could apply this to
> the tags too, by only showing tags for current language (of the logi)
> and also tags with no language and additional to this there could be a
> global language option to show a mixed of all understand languages by
> the user...

I understand what you say here, but this all is rather complex, and
especially hard to implement. And to be honest it seems to me to be
for 90% a solution to a problem we don't have (yet). Yes tags are
editable by all, and yes, some nasty stuff can be done with this
(like retagging a logi that has a better rating than yours) but so far
this has not happened, and if it happens there can be social checks
too to prevent it from happening...

I am sorry, but we have to keep in mind that we are limited in both
the work we can do and the complexity that current day servers can
handle at usable speeds...

> Other interesting part of this, is that I come to realize that we
> should make the action of tagging much more easy, and we should incite
> community tagging. Furthermore, the tags we assign should be shown
> always to us.

Here is a contradiction I think, with the idea of using tags for
locating logi's in the simulated dir-structure, and using tags in
large maximalist amounts... In my opinion LogiLogi should be
relatively minimalistic in nr of tags used. Also tagging should be
effortless, in that naming the location of the logi is doing the
tagging at the same time. Not much is needed after that.

In this context I also think that we should have the current tags as
default tags when creating outgoing links. They should then be
removable by dragging them to a trashcan, just like when adding tags.

> In resume, what I see is that we should get consensus in what tags to
> show by an algorithm as we do with logis. This could also be
> implemented through our current structure of Default, Extra-context
> and Extra-content tags, and defining by ranking which ones to show in
> each sub-group. Please Wybo, shade light on this :)

I've been thinking about changing the descriptions for the TreeNav
menu to "narrow context", and "choose content", or something like
that...

And maybe, just maybe we might have to hide the difference between
these tag-types from the users, and not allow extra content and
context tags anymore, and later just allow people to "copy" or "move" 
logis to different "locations" (then instantiating the tags either
as part of the main link or as extra tags).

That way we could get rid of the differences in colors too.

MISS = Make it simple & stupid

(maybe not the best acronym in English :), but you pplz get the point)

> = Ratings in other peer-groups
> Show other peergroups that rate this logi, ordered by ranking. For
> example, "Also rated by: Biologers 3.4, Politicians 2.5", to give
> another dimension of relations.

Cool idea, we currently have this in the form of 'view', 'ratings';
was for now removed from the main display for simplicity. What do
others think about it ? Miguel ?

> = What is logilogi for?
> We should write a logi about this, I might do it after discussing it
> over the list. Logilogi is a platform for rational debate of ideas and
> concepts. Now, this is more of a objective than a description of what
> it is for. First, we should differentiate between; what could LogiLogi
> be used for, and, what's the objective of logilogi.org, which are very
> different things. We know logilogi could be used for managing
> information for different purposes and that it's unique in it's
> features. On the other hand, logilogi.org aims to be an application of
> LogiLogi  for the rational debate of ideas and concepts as said
> before. This differentiation was critical when I intended to explain
> LogiLogi to non technical people.

As I see it LogiLogi is intended for philosophers, for working out new
ideas, and exploring new concenpts. The peergroup-system, the rating
but also the dir-structure with dynamic resolving are all aiming
towards this goal. Especially being able to write about different
aspects of concepts and/or ideas in sub-(sub, etc)-dirs is important
here, and it was also quoted as one of the wished for features by the
philosophers interviewed by the first Gip-team (in Dutch:
http://logilogi.wiki.sourceforge.net/philosopher_interview_1,
http://logilogi.wiki.sourceforge.net/philosopher_interview_2)

> = Bulk logis
> This is a strong term to use, but helps to explain. This does include
> the spam, but not only. For example, logis containing "asdfasdf",
> logis with wrong tags (on purpose), etc. This is related to the
> deletion of logis, and this problem is solved when other content is
> created and rated, but mean while this bulk logis are still there.

I think it's fine to delete them, especially as they are by anonymous
users everyone can do this...

> Also, there are other logis that are not bulk, but neither philosophy.
> For example, if somebody writes a poem, or a logi describing himself,
> or other cases. I would like to know what's your view about this.

I would say keep them in the system, I mean we don't need to be
minimalists in terms of content, as the peergroup-system can sort
things out.

A relevant problem here is whether to show tags for logis that are
rated low in the treenav. This is hard to program, but in the end we
will need something like this. Here we should be happy to have
separated the concerns (or at least not seeing tagging as voting, as
that would make things even more complex).

Luckily enougt it will still be quite some time untill it is so far,
as for quite some time there will be enough separation as long as 
logis are reasonably tagged (poetry, history, etc).

> What will we do about this at logilogi.org? we should remain unbiased
> and allow any type of contents (while not automatic or clear cases of
> spam?), but we could end up with lot's of bulk data, tags, peergroups,
> etc... Also we should take in count external linking for
> self-promotion (another of WP problems)...

Will be a problem indeed, but adding rel = nofollow should fix this
when the problem is there.

> = Deleting logis
> Since the contents of LL are under a free license, instead of the
> "delete" action we could "detach" it from the author and keep the
> contents. This is important in many aspects. A logi could mean work by
> many people (linking, questions, derived work, remarks, etc), so I
> think this is important as a warranty for contributions over a logi.

Would sound reasonable, but on the other hand many people were happy
about being able to retract logis. It might make them less affraid of
thinking creatively and bold.

But the detatching (making anonymous) sounds good too, this at least
is what currently happens when ans user deletes his account.

> On the other hand, there could be some system to auto-delete logis,
> maybe a logi marked for deletion (or voted -2) with no votes for X
> amount of time could be auto-deleted.

Would be hard with different peergroups being around, also I think
this owuld not be a good idea with an eye to separating concerns into
separate services later on.

> = Logilogi adoption
> After my talk, Rodolfo Pilas, a pioneer of free software in Uruguay
> talked to me and made some comments and great constructive suggestions
> about my presentation, which I greatly appreciate. He thought LL is
> great and he said "now it would be great if business adopt logilogi,
> they could submit bugs and contribute back code", and that was
> something I haven't thought much about still, although is the classic
> model of free software, but I haven't thought about LL applied to
> business so this is something we could also promote and maybe us start
> doing business or installing LL as a solution for business. This would
> obviously be a modified version of LL, but there is certainly a great
> potential. This is related to the next point, could LL replace forums?

I think this is an interesting idea, but again something that we
should only consider after having made the logilogi.org site a
moderate success at least :)

> = Replacing forums
> Right after my talk, the guy in charge of the computer room at the
> university told me he would be interested to install LL over there, as
> they where thinking of installing a forum, and now he thought LL was
> much powerful, and I think this is very interesting. I would like to
> help them on this, but I'm not sure that LL will fill the need of a
> forum, so we first have to look at the needs.

Sounds good & happy, but I think, to be honest, just like LogiLogi
will never replace all/most Wikis, it will never replace all/most
forums. It's just a different beast, something with it's own
advantages for lucid discussions, for exploring new concepts, and
things like that, while forums for chitchat, for announcing
activities, etc, is not going to happen, and many/most forums are in
use for that.

That's one of the reasons I think we should open up LogiLogi into
separate webservices (TODO MAKE logi)

> = Logilogi like a blog?
> Many people compared logilogi to a blog, and although we know the huge
> difference, it actually has some similarity, since a logi could be a
> post, and the comments show under it like comments on a blog. This
> would be only in the structure, but also in the way that the
> authorship is preserved, like blogs, different from wikis, so maybe
> it's not a so bad association. Maybe we could make the logi-blog? a
> super powerful, super easy blogging system for rails? then linked with
> the ogog api? wa! :)

Again an usefull side-project, and with the separated services this
should be a lot easier (imagine to be able to add links like the logi
links to texts that you can use on your blog, or on other sites,
etc...).

> = API
> This three letters are probably going to be mentioned very often in
> the upcoming months and it will be a detonator for LL adoption. Wybo,
> shall you start tracing your ideas about this? will there be
> peergroup, rating, reference (like inter-wiki links), and content
> interrelations?

See the logi TODO MAKE logi

> = Search engines optimization campaign
> I think it's time to get exposure, and this is our medium and we
> should use it at it's maximum potential. We should start SEO campaigns
> to attract attention, define keywords we want to apeart and promote
> them. We have lot's of mediums for this with no expenses, and this
> works takes some time so we could start it right now while we also get
> contents. Contents are also the base for SEO, and logilogi is by
> nature a winner on this by it's nature, so we should take advantage on
> this, right away.

Good idea, I just added a task for this. TODO add task

> = Announcements list
> When people shows interest in logilogi I/we always invite to
> participate at the list, but the general list is sometimes a bit
> technical, or maybe talk about things that don't matter to everybody
> and could be extense like this email :) We need a moderated list to
> invite general public to use, maybe this is the announcements list,
> and start reporting on new choices we've taken, functionalities (ej:
> we have a new front page!) etc. Maybe we could start selecting news
> for a weekly/monthly diggest.

There is an announcement-list already, and then there is the blog :)

The announcement-list, by the way, still has not received an e-mail as
- maybe not good - but I still think the high priority bugs/tasks
should be done before we can get the gemneral puplic to use,
understand and like LogiLogi...

> = Donations
> Let's add a paypal account, Wybo? we could also open a campaign at
> pledgie.com, where we specify what will be the founding spent at.

I just added a task for this. Still to be honest it will be some time
untill we get donations from the general public. But it's good it's
there in case a Shuttleworth comes by :)

> = UI
> We haven't got the time to talk much about the UI modifications I
> proposed (now Wybo told me he will answer early mails later), and I
> already have new ones to add, and I think we should keep evolving on
> this as it's one of our weakness.

Indeed, to be honest we already have a quite good UI, but it needs
some more love. On this subject see the logi: Evolving UI Improvements
TODO MAKE logi

I will comment on the UI-design below. (TODO check it's there)

> = Crossbrowsing
> We've done a lot of work, spent lot's of time working for LL to be
> compatible with IE. Miguel just told me he gave up after working 2
> days to make something work in IE, and this is a no end known problem.
> I think (and Miguel too) that we should focus on FF, and then, after
> releasing a stable new version, we could think of compatibilitiy with
> other browsers. How many people use LL with IE so far? is it worth?
> many people also has FF but use IE, so if there is a big alert they
> could switch browsers or just download FF, which will also promote
> it's use. We think this would unleash the front-end development
> dramatically.

It might, but to be honest, as I already said earlier, we at least
need to support IE7 too. And it should look good, as good as in
Firefox. Of course not everything has to work perfectly when it's very
hard to do, but at least it must look good & provide good basic
functionality.

> added note: just now I came across this:
> http://www.me.com/unsupported_browser/en/ (I can't enter the site as
> it doesn't recognize iceweasel as a firefox-like browser, and it would
> not work with IE either)

TODO check.

> = Learning Rails :)
> I'm back to learning rails, knowing a bit more now so starting not
> from scratch, and spending some of my time to learn so I can
> contribute to the LL code... Hope to be active on this soon, fixing
> bugs, getting tasks done, but without leaving the UI design :)

Cool, always good to develop yourself to become more versatile ;)

---previous-mail

> I might be able to do the video editing tomorrow to upload it...
> maybe it's too late.

Looking forward to it :)

> I've been thinking of giving a talk on the faculty of Engeniers and
> other at Humanities which would target developers and philosofers,
> and in collaboration we could make a team to work on LL.

Good idea, try to do it :)

> this type of things... imagine universities peer-groups that you
> could use at logilogi.org... the api will be nice!

Indeed :)

> > logo on it, but we should make some new ones with the new logo :)
>
> we should!!! actually this one has the "wiki + tagging + rating"...
> which was good, but now certainly out of date

I will also look for a big banner we can use at booths, and a new
t-shirt design. Just added a task for this. TODO

---previous-mail

> I taped my talk which could be of use as it's spanish, and when I
> get it on ogg I could upload it to logilogi.org or maybe
> foundation.LL.  Also, I'd like to write to the blog my experience
> too, if you think so :) where to link to the video.

Blog-article would be good for that. If you want I can put it on the
foundation-server.

> > Anyway; good luck tomorrow :) Got to grab some sleep for my
> > presentation now. Might be able to stay in Barcelona untill the
> > 20th.
> 
> It all went well at the presentation, people asked questions and
> participated. There were something like 18 people. I was very
> nervous but after starting got focused.

:) Quite a good number, and as said in the reply then, being nervous
is a good thing :)

> It's been great to present logilogi, I learned a lot. Also, your
> presentation/justification is exelent.

:) As a reply to why I did not introduce myself in the presentation:
first of all it is not about me, but about LogiLogi, and seconly I
don't have that many academic creds yet, so it would not impress them
anyway. No the self is something for corridor-sessions and the bar :)

> out problems. Maybe someone is also interested in coding for the
> university... anyway, I really loved how things moved, people was

Would be really cool, try to ask them anout this again in some time,
as someone from uni coding would be a good addition :)

---previous-mail by Miguel

> Unofrtunaly I couldn't make it to go to Barcelona, I really don't
> have the money at this moment to pay a ticket. I didn't write you
> before because I have a couple of friends that are going to go to
> Barcelona, till yesterday I hoped there were going to leave before
> the presentation but finally they are going this friday.

Sad. But things like this happen, and it will be some time untill they
don't happen anymore. I am also sorry for not being able to get to
Grenoble, as the ticket to Amsterdam was as expensive as the one to
Grenoble. Also I needed to be home to help my mother in the garden and
spend the week with my mom & sister too.

> PS: today I worked a lot on LL, I am trying to fix some javascript
> errors that appear on FF3 when loading the tinyMCE theme without
> toolbar on the wizards.

Curous about this bug. Is it both in the new & old versions ?

---previous-mail

> Yesterday I went to a "pizza-conf" of the ruby users group here in
> Uruguay to introduce to them LL. It was all great, very interesting
> and I got to introduce them a little bit of LL, but I need to get
> more into the code to be able to explain better technical stuff to
> developers. I'd also like to do the same to the Ruby group at Buenos
> Aires, I'll try to arrange that later.

Cool :)

Let me know when it's so far.

---previous-mail

> about creating logis, for example about "Reality", and show
> perspectives from different schools "idealism", "materialism", and
> others. Then add some peergroup "the idealists" and other "the
> materialists"... But I don't know what you all think about this. I

Philosophically speaking it could be quite hairy, as materialists and
idealist are not so easy to set apart as it would seem at first sight.
Also I don't think it's a very good idea to create peergroups like
that. On the contrary writing various logis about reality is very good
& interesting. The Reality of Reality. (TODO create a logi)

> just found that it takes still too long for people to understand
> what's LL about, and this is mostly becouse they go straight to the
> search box and don't find anything of what they type in. This will

The cloud hopefully has mended this problem. Something still to do is
make the cloud more varied. I will give it 

> certainly change with the new frontpage, I'm sure, but good content
> and examples is also very much needed. In my talk I'll also try to
> incite people to write.
> 
> I've been thinking that sub-headings of WP are kind of logis, as
> they
> are short and describe one concept, and the parent headings would be
> the context. Wybo, what do you think about adding Logis extracted
> from
> WP?

---previous-mail

> Sorry, but just in case, this is the proposal A SVG file:
> 
> http://logilogi.svn.sourceforge.net/viewvc/*checkout*/logilogi/trunk/public/images/UI_proposal_A.svg
> 
> :)

---previous-mail

> 've been working over the UI_proposal_A.svg. Here is some
> explanation/justification of my changes and other stuff:
> 
> = Overview
> Well, in general I tried to apply some ideas I've previously
> mention.  This is not finished yet as you will notice, and I'm
> sharing it so we can work it together if you all like. I'd really
> would like to work all together to end up with a better interface
> for Logilogi.
> 
> All of this is my personal view of a better logilogi, and all are
> proposals, just that, and some of them are radical and experimental
> that should be tested to prove they work in case we all agree to use
> them.
> 
> Also as this is not finished, there are obvious bits left, like the
> sidebars that where not changed much (apart from some styling). I've
> focused mostly on the headers, tried to define estyles that would
> work site-wide, "clean-up" the logi space, enfasize the peer-group
> perspective and your power (as one of the most important parts of
> LL), the rating and also the "new logi" action, as to promote people
> to rate.
> 
> Last but not least, this is a scratch and it's not perfect in the
> aspects of positions, margins, separations, sizes (although I've
> paid most attention to them), etc. Colors for example are proposed
> but not definitive as I need some testing still.
> 
> = Colors
> Well, I've done lot's of color schemes test. I end up with blue,
> like in many web apps we see arround and also many desktop software,
> and that's because blue works very good on screen. Also I've also
> been attracted to blue links (like default) and that makes blue a
> good companion.
> 
> = Fonts
> I've used font families and sizes but just as example to work over
> the layout and other concepts, but the definitive styles will take
> another approach, and I prefer working them right from the CSS,
> although they might end up looking similar to what they are now, but
> not the same.  For example, the logi text would work better on a
> browser, somehow inkscape ads a little bold.
> 
> = Header
> I've made many tests of color schemes, sizes, shapes, etc, and I've
> found that a heavy header helps the rest of the structure, so that's
> why the heavy-dark-blue header.
> 
> = Navigation bar - too many tags
> I always tend to be minimalistic, and since some time I've been
> thinking of a very minimalistic interfase for LL, which would
> consist of only one search box where everything would happen,
> suggestion, dynamic tag coloring (assigning content and context as
> typing), and also very ajaxyfied. So that would be some radical
> approach. In this case, we would be repeating tags only two times if
> we count the URL bar as our first input.
> 
> Now at LL we've got tags repeated 3 times only at the navigation
> bar.  I do understand why they are and I also think they are
> necessary now, but we should keep it in mind.
> 
> The other thing I see problematic about the tags is it's order for
> context and content, which is wrote 2 times each way, and I think
> it's confusing. We've discussed a lot about this [0]. I think we
> should go either way, but not mix them. I still fill query way more
> intuitive.
> 
> So, I did some changes.
> 
> I wrote "requested" (like old times) but still not sure what's the
> best, maybe it's searched for:, don't know.
> 
> I kind of merged the current "search" and "searched for" bar into
> one, and split the search in two, which I think will help users to
> understand what they are doing. It's an easy and effective way I
> believe, still have to test it.
> 
> = Main menu
> I think "activity" is a more descriptive name for what I imagine
> will have that section, since we will have logi-changes, last
> remarks, comments, etc... what do you think?
> 
> Also we could use a bit more wording for "tags", I don't know what,
> but we need to make clear that there you will find all logis...
> 
> = Logi toolbar
> I've give a try to this new approach. All logi-related actions to
> the bottom, and this was because when you finish reading a logi is
> when you want to use this tools, but also becouse they disturb most
> of the time since they are not used, but this is just a proposed
> idea.
> 
> = Icons
> I started to do some approaches to icons. I tested a linking-icon at
> the searched tags showing one-to-many, they are very communicative
> and explanatory, I'd like to use more of this. I actually used them
> on first approaches but then I didn't add them again, and now I just
> placed them to see what you all think, but I'm not sure if they are
> so explanatory.  I also made a simple "logi" icon... I could start
> building other icons, but first the general aesthetic should be
> defined, in case it changes from what is now.
> 
> = Links
> Right now you see links not underlined, but I pretend to test later
> how underline works as I think is the best approach. Inkscape don't
> has underline style for text so I didn't do it at first. In HTML is
> easier to test if it works or not.
> 
> = Buttons
> I've defined a standard button style, grey background and link in
> blue, which works for buttons and select boxes, but this is just a
> test, as select boxes should probably still be default styled for a
> while, later we could do a javascript+css dropdown, which are nice.
> Also, I've made an exception of button for the "create new logi" as
> to enfasize it, and play with the association of blue with the logi.
> 
> = Overbox
> I've been thinking for a while about a logi-centered design, for
> which I mean that most things happen within the logi (marking,
> commenting, editing). Also now while using it, I realized the
> overbox for editing anything is very annoying and obstructive. My
> proposal is to not use any more over boxes for any kind of edition,
> and use them (or popovers like logilinks) just for showing any
> static information. Also popups are very confusing for most people I
> think.
> 
> By now, we could some-how fix the overbox problems by changing the
> transparent background by a solid white background (which I also think
> is nicer), and I would also suggest not closing it when clicking
> outside the box, and just do it when clicking the close cross or
> cancel, submit, etc.
> 
> = Logi centered design
> I've been thinking of ways to start doing a logi centered design and
> interaction, which means that we could select text from the logi and
> comment right there without leaving (or poping) to another page/logi,
> and modifying settings right there, maybe with a shrinking box that
> appears, all without loosing focus on the logi. For this Wybo already
> explained the difficulties, so I've been thinking how to solve them.
> 
> I've been thinking that we could print the logi without links and
> remarks and add them dynamically through javascript, and only when
> needed. This way we could have always a plain text (or just basic
> tags) so we might have more control over the logi... You might already
> though about this and maybe it's just too difficult to do, but I see
> it would be a start for the next interactive LL :)
> 
> = Next steps
> Next I'll be working on the sidebars, their content and style. Right
> now, for example, My Settings has duplicated options for peergroup as
> they are on the header now too.

'k

> = Old list mails
> While researching about the previous tagging discussion, I found the
> first mails I wrote to the list, and I realized that right now we are
> doing what we where talking two years ago we would do, and just before
> reading this I made my first logi about the first "thoughts" I talked
> Wybo about, in our first conversation on the list... things are going
> just fine :)
> 
> Well, I think that was enough, looking forward the critics.
> 
> Greetings!
> 
> [0] http://sourceforge.net/mailarchive/forum.php?thread_name=20070704201750.GA30673%40logilogi.org&forum_name=logilogi-list

---previous-mail

> Wybo,
> 
> This logi you've just extended is certainly the best I've read
> explaining the need for freedom on the web. Also, I'd appreciate
> further reading if you have.

There is not so much further reading. I added one to the links, 
autonomo.us, a recently started blog on this.

> = Libre Community Network
> My logi about "Red comunitaria libre" (which is just a tiny rough
> paragraph) has a lot to do with your writings, or I rather say that
> what you just wrote could be the base or starting philosophy point of
> the concept/idea/project I'm trying to develop. I've been thinking
> about this ideas for some time now, and I've always thought that the
> first step to take toward the concretion was to create a place where
> to debate on how to build itself up, and we could say that step has
> been taken, so next, I'll write down my proposal.

Indeed. Your logi on the Libre Communnity Network is good, I will
comment on it when I've more time again :)

> = Rating over changes
> When I read the first stub of /Free_Software/Web, I thought it was ok
> but not complete and I just rate it 3/5. Now, after the additions I
> think it is a solid 5/5. I already asked Wybo about how this was
> managed, and ratings are reset every week I think, so this is good,
> but we could do it some other way, for example it occurs me that when
> a logi is modified we could set to "modifiable" the rating (so we are
> able to rate it again one time). Other way would be to just liberate
> the rating to always be modifiable, but I guess you already have some
> good reason for not doing this.

We might do something like removing the remaining power of the earlier
vote and then add the new one. Think this is possible, you can add a
low priority task for it.

I have also been thinking about simplifying the voting in some other
ways, more on that later.

> = It's LL time
> We've come to know about other projects that are on the same or
> similar paths as LL during the last time, and I certainly see this is
> very encouraging as it gives us the notion of great moment for the
> philosophy debate online type of projects to arise. This is both
> driven by the needs and the circumstances, and I see all are
> converging now... You Wybo are certainly on the eye of the storm right
> now and one can feel it although far away :)

:)

> = Writing from peergroup?
> Does it matter what peer-group we are in to post a logi?

Currently not, I've been thinking about adding an auto-vote by the
author when posting from a peergroup.

---previous-mail

> this purpose it would be nice to have some kind of document structure
> (logis relations as talked before) so you can split up a paper in
> logis (Index, introduction... conclusion) and have them group
> together... This could be also achieved by tags, but I don't think
> tags are meant for this type of reference...

Might be nice, but the whole idea of LogiLogi is to split things up
semantically. I mean what is a summary other than a first logi, an
introduction than a summary of earlier work (link to it by subject
instead), chapter one other than a chapter about something, etc...

So I think it even might be better not to have this functionality than
to have it, and at least it is no high priority. When people want it
they can do it with tags...

> = Best practices
> I've been reading last logis submited, and this is what really get
> things going! We can already see some problems to solve for example on
> over-length logis like "Functionalism" by Kalle, that he opted to
> split it up, and I think he was forced to do something that is not
> good... I think we should deal with this problem by trying to model
> good writing practices. We could suggest good practices when the
> maximum word count is overpassed, for example in this "Functionalism"
> logi, it could have been splited by three "entities for which social
> phenomena can be functional" logis... I see a logi truncated looses
> the concept of LogiLogi... what do you think?

It is true, splitting texts over logis the way Kalle did is not the
way to go but in this case he did it because he used these bits in a
paper too, and he quickly pasted them in.

> = Multiple authors
> Wouldn't it be nice to be able to add authors to logis? many papers
> are written by more than one person... This would be part of the logi
> meta data, which could have lot's more of information, like
> contributors, references, bibliography, etc... what do you all think
> about this? what you had in mind for this wybo?

My original design included keeping track of the number of chars added
by multiple authors and then dividing the power over them but it is
overly complex, and cut by the 20/80 & KISS-rules. That is in reallife
it will work out with single authors especially as logis are 1) short,
and 2) not editable by others than the author by default.

> Also by the way, I've just read an interesting paper [0] from Larry
> Sanger, in which he asks himself "Should science communication be
> collaborative?" While reading it I found some of the problems (if not
> all) he mentions are actually solved by Logilogi, which is very
> encouraging, and we should contact him (again) to let him know
> Logilogi could be the answer (in case this mail mentioning his name
> don't call him). Also Logilogi is more oriented to humanity related
> discussions, but in the future the same model could work for other
> areas.

I was championing for this in the beginning, with him, but he didn't
listen. To be honest I think Citizendium is now already too far into a
different road to still change its policies on this. I think it's best
to first get logilogi working well and splitting it up into separate
services & making it grow & then they might be convinced & use it.

> = Text editor
> Why isn't bold style accepted? too disturbing? Note that shorcuts
> still work for bold "ctrl+b".

Just added a task for it TODO

> = Overbox
> I don't know what you'all think about this, but now that I've started
> editing at LL, I realized that it's very uncofortable the
> Overbox-way... Mostly because my browser is slowed down and for
> example if by mistake I click outside the box it looses the data...
> Also when it gives me a "too long error" the data is also lost :(

Too long error ? But logi editing is not done in the overbox. And with
the normal editing changes are not lost.

About the slowness, I just added a task for it, removing the
transparency makes it faster. And for the overboxes in general; I
think it makes things a lot simpler, because there's only one thing at
the screen at the same time. We'll have to usabillity test it with
some new pplz, but I think it is a good thing.

> = IRC Bot
> Wouldn't it be nice to have a logilogi bot? maybe to notify at the
> channel of new logis? certainly bots are very interesting :)

Would again be cool, but not first priority, as we're for now the only
peeps lurking in the channel. Stuff that makes a difference for the
users first :)

> = Recent changes RSS
> wouldn't it be nice and easy? :)

Yup, on the list.

> = Bugs
> Special characters in tags does not work right, it throughs 500 error.

Did you submit a bug for it already, as it is a bug.

> When creating a new peergroup, after entering the name if return
> pressed it seems to cancel instead of submit.

The button selection order can also be added as a task.

> You might already seen it, remarks popovers stretch too the conent
> instead of having a fixed with.

Bug.

> When logged in at en.logilogi I'm not to other languages.

Already filed.

> When canceling a remark addition or link addition, the remarks box
> (not the one in the overbox) is resized, and also, if I go back to the
> overbox for adding the link or remark it will not work right and not
> show the logi text.

Already filed.

---previous-mail

> > @miguel: about the problems with building the presentation. Did you do
> > it via:
> >
> > rake doc:tex:make[presentations/ECAP08/beamer.tex]
> >
> > As this is required, because of the small filter I added to it, to
> > have DRY-er syntax... Only after this filter the presentation is
> > turned into latex and processed with tex2pdf. See the Readme for
> > some more info...
> 
> Oh, I didn't know you could build it with rake! :P I installed texlive
> and had to learn it... good to know it too, and good you're writing
> your presentations this way, it's very nice.

Because I needed it for a different presentation too, I just extracted
it as a separate ruby-script (b-rex). I will put it online soon. TODO add task.

> > You mean that it only shows the title of a remark and then allows one
> > to open it further ? Is possible I think but might not be needed yet.
> > Also as remarks are very short (& have no titles), so showing only a
> > limited number of remarks and then a link to them all might be a good
> > fix also when the number of remarks increases (but currently no
> > problem).
> 
> What is the sorting criterial? so far is by posted date... what's
> next? rating remarks? yes/no voting?

I would say for now; nothing. Maybe expiring them after some time.

KISS.

> > Again here I think we should stay simple for quite some time to come.
> > Different color-intensities for number of remarks might be a good idea
> > on the mid time range...
> >
> > So I agree with miguel on the KISSing ;)
>
> good, it's reasonable.

Ok we agree then.

> >> way we deal with overlapping remarks/links and we could deal with
> >> multiple overlapping marks by making them more dark as more overlap
> >> (most like the GPLv3 commenting system). This style could also be only
> >> applied when the mark is mouse-over and just show a plain colour the
> >> rest of the time.
> >
> > This seems like a good idea :)
>
> :) I actually come up with this second solution after I imagined
> something like 15 colours over a logi, which was loosing KISS, and
> this other approach I imagine it very clear. I'm also willing to try
> having color for logis, like a border to the logi box, and then use
> the same color for logi-links, and then remarks would have another
> color and their marks too.

We might. It would at least differentiate clearly between html-links &
logi-links. But there would be a problem with overlaps between
remarks, comments and/or other types.

> > It's the transparencty. Same thing also on my slow EEE-pc. But is ok
> > on most fast machines...
>
> Oooook, video card maybe... we should consider other ways too... I'm
> actually very tempted to change transparency by white 100%... I think
> it would even look better.

I just did. TODO

> >> This brings another topic, that is something we've already discussed
> >> also, and it is to make the same viewing logi more interactive. For
> >> example, to add a remark, we could just highlight the text in the
> >> reading-logi and when mouse is released a popover shown with a text
> >> field and a submit button... I'm sure Miguel is willing to do all this
> >> type of shinny stuff :)
> >
> > 2 reasons not to do this:
> > - to keep the UI linear, easy to use for new users
> > - Miguela/we tried this already, but it's a can of worms because in
> >  the normal Logi view links, and what not (like other remarks) are
> >  already in there so the text-positions are wrong... Now there should
> >  be hacks possible to fix this, but it would be fragile and hard to
> >  maintain as we add new ranged stuff.
> > & users only have to deal with one thing/problem at a time.
> 
> Certainly, I understand.
> 
> >> some kind of interactive pannel, that could show contextual
> >> information about the current mouse position or action... like
> >> interactive tips... (all this was a little futuristic, maybe a couple
> >> of month ahead? :P )
> >
> > This bit sounds not bad, if the info shown in there makes sense...
> 
> Well, some things I could imagine we could show are for example, the
> information icon's text, instead of making popovers for them, we could
> who the info on the interactive panel... this panel should be position
> fixed so it's always at the same possition... It's actually a vague
> idea still, and it could also be dangerous if we use it for
> some-things and not for others, bringing confusion... I think
> something like this would work if we use it for all situations we want
> to show extra information... I'll think further about it.

I think this idea is really good, as it could also work as a spot to
show flash-messages.

Maximum sizes might be a problem.

> Here goes another idea, but it's mostly one for fun... Same as we have
> system-reserved tags, we could add one that is "motto" or "title", and
> that would be the title of LogiLogi :) it would be very nice if
> anybody could give it a try, and that the title shown would be choosen
> just like logis, by ranking, and also by peergroup!!! :)

Might be an idea, but for the a bit longer term, but not really
central to how LL operates.

---previous-mail

> > I think all the suggestions made by Bruno are excellent but I would
> > add a "simple mode" and an "advanced mode" so the UI could continue to
> > be simple as it is now. I like the KISS principle :p
>
> Certainly we should KISS. We could have 2 or 3 levels of complexity. I
> imagine the simplest mode should be almost plain text and not much
> functionality, more like a "reading" mode... maybe could be the
> default.

We may also be KISS in these complexity levels. I'd go for at max 2
levels, and just regarding the amount of details shown and showing
help-icons.

> > > For our next UI big changes, I'm willing to propose a more
> > > logi-centered interaction (also considering going back to placing the
> > > logi in the center, just making some tests on this), where things
> > > surround the logi and appear/order as needed... we are sure headed
> >
> > the best way would be that every user could have the ability to sort
> > the panels and the Logi position as they wish.
>
> mm... that could be nice, although I'm not sure if it wont confuse...
> What I meant by things that "appear/order as needed" I was thinking
> about, for example, when editing a logi, the not used sidebars could
> vanish, go to alpha 20% or something like that, and bring some other
> "editing" box could appear.... anyway, I'll try to work/think it out.

As said earlier, I think the toolbars (most at least) also provide
context so while they could go alpha after some time they should be
there in the beginning.

> also, today I browsed LL over a small screen (800x600 I think) and
> having the logi placed to the left was very confortable and it look
> good, and I thought that if we had the logi at the center (with left
> and right column) I would had to scroll to read the logi, so, I guess
> each approach has it's advantages...

'k

> > Today I started writing my rapport for my stage, next Wednesday I will
> > have my presentation so I will not be developing as much as the last
> > weeks for the next days

@Miguel, I'm, interested in reading it too :)

> > Greetings
> >
> > Miguel

---previous-mail

> = Remarks =
> The "remarks" are a very useful feature, and are clearly showing to be
> a great way of quick-participting. We are still in a "just the
> essential" version of Logilogi, and remarks were a last moment
> addition (at least to the UI), and this is just showing the tip of the
> iceberg. Logilogi is headed the right way from the beginning :)

:)

> == On/off ==
> Allow to turn them on/off. I'm not sure where to place this right now,
> but I think on the LogiRemarks would be right.
> This could be taken like part of the "user interfase" settings, that
> we've talked before of setting different levels of complexity.

Not KISS.

> == Markup ==
> We've talked about this before, and we should really get organized and
> think and discuss on what markup to use site-wide for it to be
> consistent, on all aspects of UI, or we could end up with something
> confusing. Instead of just talking about it, I should get down to work
> and start doing it... I'm writing a wiki page [0] detailing what is
> currently at the public Beta. De-glossing the structure this way let's
> me appreciate the elements very clearly. Also, while justifying and
> explaining each element, we are also writing documentation and we
> could re-use it.

We can, but also cleaning up CSS and such is a start. Like I did with
the panels last week.

> Also publishing features early (beta) lets us see how it evolves by
> the needs. For example, I'm appreciating how nice the link-popovers
> are to show conversations, and actually work very nicely, so remarks
> could be shown there (as right now) and use collapsible remarks
> titles... I don't know how this could be done, what do you all think?

I think it's good. The collapsable titles is better, but even without 
it's already good too :)

> == Coloring and styles ==
> === Colorful option ===
> If we create now the Remarks types (question, addition, etc), then we
> could use colors for each "type" of remark. It could be interesting to
> actually be able to set marks colors in different layers, for example
> mark text by amount of times remarked, by creation date, by user, etc.
> We could differentiate a site-wide a special color for logis, included
> derived works.

Sorry, again way too complex. Color intensity for nr of remarks is, for 
the short time, I think how far it should go.

> I've been thinking about light background colors mixed with underlined
> style, but I'm still not convinced about how to do this. The main
> problem is overlapping remarks, and them mixed with links. I thought
> we could deal with this with transparent color background and so there
> should be a mixing, but I'm not sure this will work.

If we do logi-links as non-underlined blue words, html-links as
underlined blue words, and remarks as words with a reddish background,
then we cleanly separate the dimensions, and have simplicity.

> === Not-so-colorful option ===
> We could also opt for a not so colorful way, like assigning colors by
> content-type, (logi, remark, external link?). If we use this method,
> we could show clearly different the remarks and links, for example,
> links underlined and marks "highlighted" soft background color. This
> way we deal with overlapping remarks/links and we could deal with
> multiple overlapping marks by making them more dark as more overlap
> (most like the GPLv3 commenting system). This style could also be only

We agree, except for the underlined part :-) 

> = Comments or Derived work? =
> I guess we are still looking for the right way to call it, certainly
> "derived work" describes it very good... I also thought "derived
> logis" could help to explain that comments/derived-works are also
> logis.

Good :)

> I've just written most of what I've been thinking about during the
> past days. I'm also very tempted to start writing this kind of stuff
> right to LL and so we can collaborate over there, what do you'all
> think?

I think it's ok to move some things over to LL, but let pplz know on
the list too, especially as long as we don't have the RSS-feeds yet.

(The plan is also to have RSS-feeds for context-tags, so pplz can keep
track of what happens in the 'dirs')

> [0] http://logilogi.wiki.sourceforge.net/UI+analysis - The lists font
> sizes are decreased each list-level so it's not very clear... take a
> look at it at the GUI editor mode... I also thought about starting to
> use LL as the development wiki, through a LL-dev-peergroup... what do
> you all think about this?

TODO

---previous-mail

> Also, I wanted to remark about the current fixes and issues. We've
> alread gone throught the most nasty problemas of crossbrowser, mostly
> rounded corners that you solved greatly, so now, to go through a new
> interfase would not be so much work, and we will take in count from
> the beginning the current needs (new features, frontpage, etc), and
> others... This is also why I'm using the same elements and moving the
> arround, not becouse it's easier, but in order not to change so many
> things. In my current examples though, it could seem different because
> I removed the background boxes (and colours), but that was just
> testing...

I think it's good to change the UI in small steps.

(About the background-boxes grouping things, this, I think reduces
complexity, in the sense that it groups things, so it breaks it up to
at max seven elements on the screen.)

> > While the colors look faded on one, there is surely enough space to
> > see the Logi & panels on both of them (On my EEE-pc with 1024x600 on
> > the other hand all one sees are the top-bars & the title)
> 
> I don't understand this point. What I intended to do was actually to
> design LL to even fit mobile phones (if it was html :). The sidebars
> would float left and go to the bottom of the logi if there werer no
> room...

I'm sorry, but this all takes time, and LogiLogi is not really
something that needs to be used on mobile phones; by the way, soon
enough phones will be running Firefox/IE and have 1024x768 screens.

Again KISS.

> Ok, I have to explain here a little bit. This layout was thought to
> have more ajax functionalityes, and the search and tagging is one of
> them. I whought of tags suggestions while typing and to add one tag at
> a time, while you could add multiple, the search box is small :)

Sounds nice, but auto-completion is also possible with multiple
consecutive tags, and this way the site/js is not in the way, I mean
having to do enter between tags, or stuff like that makes it slower...

> > - the panels are too close together & I think better when panels
> 
> Certainly, it needs air... I'm not sure why I get obsesed with space
> and shrink it all together...

Indeed, in that sense the current UI was/is better.

> > - the little calendar and the by - author name look good, and are
> >  missing here... (author name is there, but in a panel)
>
> Yes, I also agree with you that they look good how they are now, but I
> thought it would be more clear and usefull if it was all logi-related
> information on the same place, but this is relative and we could try
> to fit the most relevant information of the logi, on the logi
> itself... Also about the calendar, I do like it, mostly when it's
> applied to blog posts, but I don't think it's being of use in this
> application, but this is probabbly becouse my perception of the
> elements is disturbed by the use I do of LL, proabbly someone else
> uses it and realizes that the date is over there and that is the date
> when it was created/modified... I would go for a plain boring "last
> modified: 11th June 2008"

Might be true, yes, as dates are less important with philosophy than
blog-posts. So we might move it, or remove it. Still pplz seem to like
icons/visualisations more than textual stuff, so we should see where
else we can use icons.

---previous-mail

> == history & diff ==
> About the history/diff code, Miguel proposed an in-line aproach to
> version comparison, plus it's dynamic display (like good web2.0 LL is
> :), which I think both are very interesting... I first thought going
> inline for comparison would be a mess and hard to deal with, mostly as
> I don't have many examples of inline diff comparison, but after
> researching a bit, I found that even it's not a common approach, it
> could fit our needs, since we dont want a so technical tool, but more
> a more graphical one...

I'm really happy with the diff-UI :)

> === Tags ===
> We should decide whether we will compare the code (including tags) or
> the text (output). This I would guess was already decided for the
> current alpha version of the diff, and for what I can tell, the choice
> was to compare the output text, which I think is the best approach for
> our needs, so this way we will get the user away from the code in all
> cases, when editing, diffing, adding links, etc.  Right now it's not
> working as spected, but I guess this is because of the alpha state of
> the code. For example, changing "Original title" by "New title" right
> now in the diff looks like this:
> 
> <span class="diff_new"><h1>New<span
> class="diff_old"></span></h1><h1>Original<span class="diff_both">
> title</span></h1>

Indeed, this seems like a small bug (but not a high priority one, as
it currently looks good in both IE and FF).

> and a diff of changing "original" by "modified" in the paragraph looks
> like this:
> 
> We should define which tags we are working with, not many by the way,
> h1, h2, p, ol, ul, li, em, strong, sup, sub. With this tags, we could
> define the following way of diffing. We could diff the plain text
> inside structural tags, like headings, paragraphs and lists (items),
> and we should deal inside this tags with the text styling tags, like
> em, strong, sup, sub. This is the best approach I can imagine, and
> maybe, this is already where we are heading to, I didn't talk with
> Miguel about this. This way, the previous examples would look like
> this:

Doing sub-diffs has the problem of not seeing overall changes. And
taking out the styling before diffing misses styling changes.

These simple stylings I see as part of the text, which should be
normally diffed with the rest of it. Non-closed tags, etc, can be
fixed, in most cases, with running it through HTMLtidy.

But indeed, the bugs here can be fixed in a future diff version, but
as the diff works fine enough now, I see it as a very low priority 
task to improve it.

It still can be added to the tracker though.

> <h1><span class="diff_new">New</span><span
> class="diff_old">Original<span class="diff_both"> title</span></h1>
> <p><span class="diff_both">This is the </span><span
> class="diff_old">original</span><span class="diff_new">new</span><span
> class="diff_both"> paragraph text</span></p>
> 
> Also I don't know for which cases is the diff_both tag used for.
> 
> === Version selection ===
> For the version selection, I would certainly go the wikipedia style,
> which is very intuitive and functional, and it dont have to deal with
> 3 versions comparison... will we deal with this? do we need it?

This is well done by Miguel now :)

Wybo