Victor Engmark wrote:
> Davi Leal wrote:
> > Victor Engmark wrote:
> > > > https://gnuherds.org/Timeline.php
> > > > /news or /timeline ???
> > >
> > > Depends on whether the suggestion to move the data into a sepakrate
> > > news page is followed through.
> >
> > The current Timeline page is separated. Move what data?
>
> Most of the data on the Timeline page is news. The work items which are not
> done should probably be Savannah tasks (are they already?). How about
> linking the Timeline page only from the "Status: Beta" text? I think that's
> a better targeting of the audience interested in this kind of thing. Casual
> users won't be looking for this information in the main menu - It's for
> people interested in the project, not the functionality.
The Timeline is a general view of the project *roadmap*, not a detailed
task list. For example, it just says "Translate to other languages..." but
the list of languages which the project is being translated is detailed at
the Savannah task manager.
Awright, maybe it should be called "Roadmap"?
At the webapp apache log, I have seen that people who click several
pages, click too the Timeline. Maybe to know how the project is going,
and to know why there is not job offers, etc.
I think that even when we finish the beta phase, there will be always a
roadmap, a timeline, at least to show an abstract of what we have done,
and to ask, "And now what?" to get ideas.
Yes, but that's not of interest to general users. IMO, we should cater to users in the first place, and have a single link for everything that only those interested in the project itself would use.
The task "Move to offices managed by FSF staff" was already registered at
savannah as "Move to another hosting".
OK, then I propose to remove it from the footer.
> > > > https://gnuherds.org/FS_Business_Networks.php
> > something as /business_network_models ?
>
> That's long, but maybe it'll do. I believe this is another example of
> information the casual users won't be interested in, and as such, it should
> be moved off of the main menu.
I think the menu must list always all the information which is at the
website. That is accessibility too.
You don't want to have all information available one step from the front page. That's gonna be more information than
anyone would care to read. Accessibility doesn't mean you have to have links to everything everywhere - In fact, simplicity is a major part of accessibility.
Maybe you mean that this information must be only shown to the logged
users?.
No, it should be available to those few who are interested in the project per se
, not just as a service to them. But preferably not at the cost of several links in the main menu which will be useless to the general public, which is our primary audience.
> > > > https://gnuherds.org/e-Voting_SIG.php
> > > > /evote ???
> > >
> > > This could be part of a general FAQ.
> >
> > Yes, but moving it, we will get an empty o removed "Special Interest
> > Groups" section. Maybe it is convenient. I am not sure.
> Do we need it?
It is good to show, without any doubt, that we are a true-democratic
association.
That will be shown only by our actions, not a page on our website.
> > > It looks as though a lot of the content could be removed:
> > >
> > > - The links from the "Bringing free software to voting booths"
> > > article; just link to the article itself, if necessary.
> >
> > It is good we link to the reference from where we have taken the
> > information. Isn't?
>
> Sure, but that's enough information. The current page also contains copies
> of links within that document, which is unnecessary.
Our intention was to list all the possible e-voting options at our page.
So listing the options was the main goal. We just added the reference to
the article from we got those e-vote options. Do you think yet it is not
right?
The only issue is that there are links on the site which have been taken directly from some article, plus a link to the article itself. Unless we quote the article, there is no need to include a link to it.
> > > > https://gnuherds.org/Person.php
> > > > /person
> > > >
> > > > https://gnuherds.org/Company.php
> > > > /company
> > > >
> > > > https://gnuherds.org/non-profit_Organization.php
> > > > /nonprofit
> > >
> > > All these should IMO be at "/register", with a single link from the
> > > front page, as discussed .
> >
> > This will take some work. Therefore it will not be so easy add this to
> > production. First we will have to fix this kind of thing. Anyway, I like
> > how directly you get an specific form for fill all the Person, Company or
> > non-profit data.
>
> Yep, but our front page should be as lean as possible, to make sure
> prospective users are immediately aware of where to go to register. It's two
> fewer links on the front page, at the cost of one extra click for those
> users who are trying to register.
>
> As a mitigating measure, I propose we change the registration links from
> "New X?" to "Register X." That way it's clearer what we mean.
OK. So we can the below one as their logical URLs, or something similar:
/register?e=person
/register?e=company
/register?e=nonprofit
OK, good. How about renaming the parameter "type" or something?
However, when the person is already registered and logged, we could use
the below logical URLs, which will point to the same physical Person.php,
etc. URLs:
/person
/company
/nonprofit
or maybe better just:
/identity or somethink similar
What do you think?
IMO, the first solution looks best. "identity" is very impersonal.
> > >> https://gnuherds.org/Manage_Job_Offer_Applications.php?JobOfferId=XXX
> >
> > state to: "Received", "In Process", "Ruled out", "Finalist" or "Selected".
> >
> > Maybe this? "/jobs?action="">>
> That's good, but it's really candidates which are being managed. How about
> "/candidates?action="" It's longer, but IMO more clear.
The action is realized over the job or over the candidates?. The action
is carried out over the candidates of a job offer.
I thought is was better having all action related to jobs as /jobs.
Maybe your option is better, but I am not sure. We can take into account
both options, and decide later.