gnuherds-app-dev
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Home.php reviewed + brainstorm -- avoiding huge redesign

From: Davi Leal
Subject: Re: Home.php reviewed + brainstorm -- avoiding huge redesign
Date: Wed, 18 Apr 2007 11:45:40 +0200 (CEST) 
Victor Engmark wrote:
> Davi Leal wrote:

> <link rel="alternate" type="application/atom+xml" title="Job offers"
> href="http://gnuherds.org/jobs.php?format=atom"/>
>
> in <head>, users who prefer feeds (maybe they are using many job sites, and
> can't be bothered reading them unless necessary) can get all our job offers
> without even reading the front page.

Cool


> Another idea wrt. this: We should provide job feeds for any and all
> searches. That should be relatively easy if we use the same PHP file to
> output HTML and RSS. Just add a "format" parameter (like in the <link>
> above). This is one place where XHTML is useful: We could use the same
> module to output markup for the web site and for feed items.

I like that idea: two user interfaces: output HTML and RSS.  However,
about XHTML, does it conflict with the mobile devices support goal?. Could
we get all this fitting together?. Again, the same questions?. :)


> > - A <div> with new job offers could be useful for new users to gauge how
> > > much traffic  we're getting, and for casual users who don't want to use
> > > RSS or email.
> >
> > Well, such users can take a quick look at the JobOffers list, sorted by
> > date. Isn't it?.
>
> Yes, but if we could show that on the front page, that's a lot of users
> which save one click. We'll just have to see if it's worth taking up the
> space.

Please, add a Savannah task which explain we must try this idea.


> > > - Contact information could be useful, but we might want to use a
> > >   form to avoid spam. Dunno which is most effective.
> >
> > The View_Job_Offer pages are public, but they do not show contact
> > information. Anyway, I think we must check it.
> >
> > The View_Qualifications pages are no public, only the JobOffer owner to
> > which such qualifications are subscribed can access it. It is by design
> > of the webapp, and checked by the Access Control Lists.
>
> I don't think it's enough to make pages with email addresses non-public

Spam is no the main point here.

We decided do not allow public addresses in job offers to avoid people
sending the employer an email, instead of filling its qualifications and
subscribing to the job offers.

> (besides, I think the contact information should be public).

>From my experience, if we allow the employer expose her/his email, they
will get emails from guys which:

  1. will spend her/his time

     People will ask a lot of information, which anyway must
     be described in the own job offer.

  2. that emails will not show all the information required to
     compare with the candidates who has filled
     the qualifications form and subscribed.


Note that jobsite types are a _tool_ to make it easier the selection
process to employer, and make it easier the subscription to candidates.
All the jobsites I know does not show emails in the job offers.


> >    - Logo + title linking to the front page.
> >
> > Instead of the herds photo?. Good, very good point!.
>
> I don't deserve credit for this - I just listed it for completeness, and
> used "Logo" instead of "Picture" :) But you have a good point! Is there a
> good designer among us?
>
> Logo ideas:
>    - Many copies of the gnu from the GNU logo in profile, repeated behind
>    each other, fading towards one side to give the illusion that there are 
> lots
>    of unseen gnus, and that there is dust obscuring them.
>    - One or several gnus, seen stampeding in the direction of the user.
>    Maybe a bit intimidating for a job site ;)
>    - A field of grazing gnus, from above or the side.

Please, add a Savannah task for the Logo idea. You can copy and paste the
above sentences.


> By the way, I know it's probably sacrilege at this point, but the name is
> very similar to GNU Hurd, and I don't think the ensuing confusion will help
> us. What do you think?

Interesting comment. That is my rationale: Being similar to "GNU Hurd" is
the only bad point which I know right now, about that name. Forgetting that
subject, I personally actually like the "GNU Herds" name for this king of
Association. I know others guys like it too.

Besides, we are already known by that name. We have announced using that
name. We are getting visits via google search, etc. I think it is a bit
late to change the name.


> One comment: If we add a link to the title, it will change its color. Maybe
> > that will not be good for the look&feel.  Therefore, is the link at the
> > title actually convenient?.
>
> We could force the heading to be formatted not to look like a link, but
> you're right. Also, it should be enough to have a link on the logo; that's
> where users expect it (I'm pretty sure I read that in Jakob Nielsen's
> Alertbox).

OK. Link only for the image/logo, not for the title.
Please, add a Savannah task.


> > Things I think we should not include on the front page:
> >
> >    - A <div> with site news. On a service site like this, most users
> > >    won't care a bit whether we've changed languages, moved servers, or
> > >    got a new developer. It could be served as a feed or a secondary
> > >    page, however.
> >
> > So, you propose to add a news page?.
>
> Yes. Our "Timeline" page does the job pretty well already, and we could add
> bits and pieces as we go along. If we add those bits to an Atom feed file
> (or create an Atom file from the database), I already have XSLT to make a
> web page from that.

Cool. Add a Savannah task. As we have a lot of thing to do, I think it is
good we add Savannah tasks to do not forget it.



How to manage all this work, I propose follow the below steps:

  1. Convert the webapp to <div>s + CSS, as we have already begun to do,
     realizing too small modifications, as the hackers index grouping,
     etc. but avoiding huge redesign.

  2. Check that it is HTML 4.01 Strict,
     and move it to production.

  3. Realize the needed translations.

  4. Carry out the huge redesign.

  5. Coordinate with the proposed Klaus' architecture.


The main point is avoid huge redesign now, but taking note of the good
ideas about it at our Savannah task manager.

Davi
reply via email to
[Prev in Thread] Current Thread [Next in Thread]