[LogiLogi-list] Gui-design and development.

First of all welcome to you Miguel, I've already heared much good
about you from Bruno.

If you want to get developer-access to the site you can send me your
user-name and I'll add you.

Bruno, my reply is a bit later than it would have been had I not woke 
up this morning with one swollen eye-lid, making it risky to use my
contact-lenses. It's getting better now, but still it's quite strange, 
as I never had this before...

I think we can better discuss these things over the mailinglist now
Miguel joined, and also in general, because some others might be
interested in it too, and as long as we use meaningfull subject-
lines, others can easily skip the messages... So I replied to the
list.

> >On integration it has to be the possible to only fill the div if the
> >link is clicked, but this is no problem I think.
>
> Ok, so loaded with Ajax. There should not be a problem with this.

Nice.

> >I agree with you that we should also find some other way - like roll-
> >over help - besides relying on the colors only for meaning.
> >
> >A minor issue is that the colors got mixed (green is requested now,
> >for the top-bar at least)...
>
> Ok, sorry about that, I got mixed. I got mixed before working on the
> link, when I was working on the header. I started to work on migrating
> some tables to divs, what do you think about it? (no tables for
> design, just to order tabular info). The header also doesn't have a
> background image anymore, the tags are list items, what do you think
> about this?

Really nice!, even twice ;)

> (this is answered later in this mail, thanks! ;)
> 
> >Actually blue is for the requested, and green for the received
> >concepts, and white/greyish for the logi. The background-coloring
> >of the link is a good idea, but we have to make it different colors
> >than the ones for requested and received to prevent confusion.
> 
> Ok, I just thought that there really is a parallelism between the link
> colors and the navigation or ubication colors. I also thought that in
> the top_bar there could be a dropdown menu that could show other logis
> for the requested tags/url

Adding a drop-down menu to the top_bar, or even to the url_bar, so one
can click the =i1 in 'LogiLogi,s1 @en =i1 =v1' and then see a list with
the other logis, and simmilar for different concepts, so LogiLogi,s1,
if clicked shows a list of other senses of the word LogiLogi, would be
a good thing.

> How will this be approached if the word is a number? what if the
> characters are not even?

The word is just a string, so a number would also have it's first part
to point to the best logi and it's second to the links & logis.

If the number of characters is not even we round down or up, a pretty
random choice.

Words shorter than two characters are not linkable for now, and later
we can add a special rule for those...

> >I also miss the requested_, received_ and logi_line's in their old
> >function of adding pretty browser-independent top and bottom borders
> >to the url-bar and menu-items. Or do you disagree with them ?
>
> I didn't played attention yet to the borders, thought I saw them, I
> didn't get the meaning of them, please explain me the concept. I'll
> add them now and get the colors correctly.

The borders have no different meaning than the requested, received,
and logi-colors they match. The're merely nice, and to make the color-
distinctions clearer.

> >A screenshot of the old Manta Gui as it looks in my Firefox is
> >online here:
> >http://logilogi.org/pub/img/manta-old-gui.jpg
> >so we're talking about the same things...
> >
> >> Check it out and let me know what you think.
> >
> >It's great, I'm especially enthausiastic about what you made happen
> >inside the url_bar_top! It scales perfectly with differing font-sizes
> >now!
>
> Thanks!
> I'm glad that you like what we've done.
> 
> We really have to define with which JS library to work with. Miguel is
> used to prototype.js (he is now in the mailing list, hola!). You
> talked about RJS, I researched and it looks like it's incorporated in
> the new RoR version as standard library, dought it doesn't has many
> functions? help me on this.

RJS also uses Prototype. So using these where possible would be good:
http://api.rubyonrails.org/classes/ActionView/Helpers/PrototypeHelper.html
http://api.rubyonrails.org/classes/ActionView/Helpers/PrototypeHelper/JavaScriptGenerator/GeneratorMethods.html

But for functions not yet in Rails you can safely use plain Prototype,
because it's likely they will be added later on.

This is also a nice spot to check:
http://www.rubyinside.com/16-rjs-resources-and-tutorials-for-rails-programmers-5.html

Note however that we are on Rails stable, not edge, this because
engines and plugins usually do not work very well with Edge.

> As told you before in this email, I'm working on migrating the tables
> to divs when they are not for displaing tabular or sortable data. Let
> me know what you think. Could it speed up your coding to get rid of
> tables?

It will not make a difference in terms of coding. The main advantages
to gain are scaling font-sizes, and neater html-code. 

But I also think that we should remain pragmatic, and not remove all 
tables where they are just easier or simpler for layout-purposes. Also 
because the tables are only in one place, so the day that browsers 
will stop supporting tables the way we know them, we can change them
in no-time.

Also a particularily hairy problem is having a 3-column layout with a
footer that keeps neat when any one of the 3 columns are longer than
the others (currently flawed in both http://www.logilogi.org:3000/ and
your file, but ok in the layout of LogiLogi.org).

> I've started to try to organize the LogiLogi UI structure as it is now
> and would like to publish it at the LogiLogi.org under some section
> where we could justify and discuss the UI approach.

That's ok. 

http://en.logilogi.org/MetaLogi/LogiLogiManta_GUI seems a good
location for publishing info about the GUI that needs to be kept
around longer than in the archives of the mailinglist (which are
not working a.t.m. by the way, but it's a low priority bug on
Sourceforge).

If you mean adding the file, it would be nice if you included it 
in the svn repository. That way we can all see it progress, and 
I can also add it easily to www.logilogi.org:3000 then for non-
local use (testing in different browsers and such). Putting it 
under public with a name like new_url seems most logical to me.

Great work so far, and welcome Miguel!

Wybo

> >Wybo
> >
> >> --
> >> Bruno