[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Herds mockup

From: Davi Leal
Subject: Re: GNU Herds mockup
Date: Tue, 12 May 2009 00:13:36 +0100
User-agent: KMail/1.9.9

Matt does not know the project in depth.  Anyhow, IMHO any feedback is key to 
follow improving the project, if we can.

Nicodemo wrote:
> Antenore Gatta wrote:
> > Matt Lee wrote:
> > > Davi Leal wrote:
> > > > Let us know any bug, comment, etc. The more critical the better!
> > >
> > > See my attached screenshot. Everything I have covered in green
> > > should not be shown, either where it is now, or at all.

IMHO, Matt suggests center the user focus even more on the active offers. 
However we must not forget the webapp has other use cases than just users 
reading offers, e.g. there are users who just want to log in to update his 
qualifications, look at his application states, add complex job offers, 
classify skills, etc.  Webapps with such use cases usually show initially the 
log in page to make it easier get into the webapp and begin to work with 
those data.

Some other Matt's suggestions are not technically doable or are doable but 
raises regressions. Read below.

We must take care to avoid any kind of regression. As the project is more or 
less stable we should only modify it if we are 100% sure.

> > > Don't put the list of languages at the top, but them at the bottom.
> >
> > I agree with almost everything you say, but language bar there is
> > really nice IMHO. Just it's not functional if we will have too
> > many languages... 

I agree with Antenore.  Both the language bar and the logo heading are very 
cool in aesthetic, etc.

> > > Put the AGPL logo at the bottom.
> >
> > I agree, bottom right, it balance well with logo.

IMHO if we do not move the language bar then there is not need to move the 
AGPL logo at bottom.  The AGPL logo would looks odd being alone at the 
bottom. IMHO it would break the current aesthetic too.

> > > Remove the login box entirely -- instead, prompt the user to login
> > > when it is needed.
> >
> > I agree 100%. Several sites are doing this, asking to login only when
> > the user needs to access/modify sensible data. It's less annoying
> > and it makes people less worried about a registration process.

I agree about the possible bad effects of showing the login box.  If you 
forget about such 'fears' you will have to agree about the login box in every 
page is handy.

Maybe several sites are just prompting the user to log in when it is needed, 
but such sites are more simple than GNU Herds.  We can not do it with GNU 
Herds because there are use cases (users managing data) which requires an 
explicit log in.  Webapps that manage data use to show initially the 

I do not see the value of hidding the log-in or registering process. IMHO 
prompting the user to login when it is needed has similar bad effect on such 
users or even worse. That is to say, when finally the user get such 
log-in-registering-box prompt he usually thinks  "Have I to register? !!!"

> > > Do not have four links for registration. Do not have one. When
> > > the user needs to register, let them register, and give them
> > > LESS options, not more.
> >
> > Agree... As above.

There are already lot of use cases where GNU Herds auto-register users.

IMHO we must not over simplify the project just because it could look a little 
easier to use to some persons.

Note that other similar projects has two link to register, one to register 
workers and another to register employers.  We have two more because the 
entity type (person, cooperative, company or non-profit) is part of the 
information which is used to select an application.  IMHO two links more at 
register time are not going to kill the project.

Let's be sincere, what will kill the project is not how hard to use it is, but 
the lack of offers. Companies do not like a project as this one.  At the 
right time we should to communicate better; "Marketing".

Companies will not support GNU Herds.  I know one which has rejected using it. 
Even the FSF created its own job listing.  Cooperatives and some persons are 
the only ones who are supporting the project.

Anyway, maybe it is true we will have to hide the log-in box behind a log-in 
link, etc. Time will tell ...

> > > The menu on the side should be along the bottom.
> >
> > Can you provide an example?  I don't understand this point.

That is the menu layout.  It is not applicable to our case due to 40% 
of the gnuherds menu entries depend on the log-in-out state of the user. IMHO 
a horizontal menu would be less usable than the current vertical one.

> > > The email contact should be along the bottom of the page, not the
> > > content.
> >
> > I think it's a good idea, in this way at any moment the user can make
> > in contact with us.
> What I read here is that there should be a vertical layout to the web
> page, where the most important parts of the hierarchy starts at the top.

No, here Matt is talking about moving the sentence which is located at 
content-bottom to page-bottom.  I would agree, but unfortunately moving it 
from content-bottom to page-bottom being doable raises layout regressions :(

> The worst case is: if you use text, screen reader, or mobile browsers,
> you may have difficulty navigating to the information and features you
> were after.  I can tell you that GNU Herds is especially hard to use
> with a text browser such as elinks or lynx. A vertical layout would
> help to ease those browser issues.

IMHO any complex webapp is harder to use in elinks or lynx than in FireFox. 
Yes, GNU Herds has grown in features and so in complexity.
For screen reader or mobile browsers, it is usual develop another special 
interface specially oriented to such users.

IMHO the project is now supporting FireFox, Konqueror (Safari), IE 7 and Opera 
(with some small bugs due to Opera fault) and elinks, lynx, etc. (with 
usability problems due to the site complexity).  Warning: I have not checked 
IE 7 lastly.

The project is not intentionally supporting screen readers or mobile browsers.

> > > If there are no job offers, don't show any.
> >
> > Yes and not... I'd rather prefer to have always job offers... One
> > day we will have always something to show... Anyway can you please
> > explain better which is the point.

IMHO, in the general listing we must show at least RSS and buttons to follow 
or create any offer type.

Maybe what Matt was thinking is the bad image which the project presents when 
users see some empty entries.  That is because the FSF job site [1] did not 
removed any job offer, even if they were not active, up to the listing was 
more popular and the stream of new offers was good:


I agree with Antenore about this point. That is to say, we must show the empty 
listing too, so people can see that besides donation-pledge-groups they can 
post too actual job offers.  We are showing the empty list, the RSS link and 
the button so that posting be quicker. So users do not even need to click 
the "Post offer" heading button.

> > > If there are no volunteer position don't show any.
> >
> > As above...

As above.

> > > The site gives NO clue as to what it is or why it exists.
> >
> > Not really!!! Go to the home page and read... ;-)
> >
> > Well, it can be improved and I agree that we should insert
> > an "About us" section, but it's not so bad at the moment,
> > isn't it? 

Users have just to click in Home, Charter or FAQ, which besides are linked 
among them.

I propose renaming the 'Home' page to 'About us', due to such page actually 
talk about us, about the project and who we are.  Done at production, but not 
committed yet.

> > > What is a 'free software association' -- explain in terms people will
> > > understand.
> >
> > Yes, but remember that who comes to gnuherds is someone who know enough
> > well this words... It's out of our scope to explain to people what is
> > the free software. Anyway it can always be improved.
> Is this not defined on the "Charter"?
>    "The name of the Association shall be GNU Herds, to be known
>     publicly as GNU  Herds - Free Software Association."

> > > Positive feedback:
> > >
> > > These icons are nice -- why aren't they on your homepage?

I have added such icons at . Done at production, but 
not committed yet.

Such icons are too, in its small version, at and other 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]