[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Microformats and logical URLs -- mod_rewrite
From: |
Davi Leal |
Subject: |
Re: Microformats and logical URLs -- mod_rewrite |
Date: |
Wed, 25 Apr 2007 16:42:46 +0200 (CEST) |
Victor Engmark wrote:
> Davi Leal wrote:
> > The Timeline is a general view of the project *roadmap*, not a detailed
[...]
> Awright, maybe it should be called "Roadmap"?
Sure!
> > 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.
Could we use the harcker's guide as that single link?. We could move the
Roadmap(Timeline) to such section.
> > 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.
Done!
> > 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.
I understand now!.
> > 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.
I understand.
> That will be shown only by our actions, not a page on our website.
Agreed. Could you add a Savannah task to move the e-Vote section to
the FAQ?
> > 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.
I have removed the reference to the article. Now we just lisk the options.
Let me know what you think.
> OK, good. How about renaming the parameter "type" or something?
/register?as=person
/register?as=company
/register?as=nonprofit
What do you think, "type" or "as"?
> > > >> https://gnuherds.org/Manage_Job_Offer_Applications.php?JobOfferId=XXX
> The way I figured was that everything on the site is related to jobs, so
> unless we're dealing directly with them, we should point out which kind of
> object we're handling. This form will be fundamentally different from the
> one used to create job offers.
OK, so we will use what you have proposed:
"/candidates?action=edit&job_id=XXX"
> Apropos, maybe it's better to change "/jobs" to "/offers" or "/positions",
> since there is already some ambiguity WRT the semantics of "/jobs".
Let's view all at one again:
gnuherds.org/GNU_Herds_Hackers_Guide.php
/development
gnuherds.org/FS_Business_Networks.php
/business_network_models
gnuherds.org/Lost_Password.php
/password
gnuherds.org/Person.php, etc.
as exposed above
gnuherds.org/View_Job_Offer.php?JobOfferId=XXX
/jobs?id=XXX
gnuherds.org/Qualifications.php
/resume
gnuherds.org/Manage_Job_Offers.php
/jobs?owner=me"
/offers * Maybe that is better?
gnuherds.org/View_Job_Applications_State.php
/jobs?applied=yes
/positions * ???
gnuherds.org/Job_Offer.php?JobOfferId=XXX
/jobs?action=edit&id=XXX
gnuherds.org/Manage_Job_Offer_Applications.php?JobOfferId=XXX
/candidates?action=edit&job_id=XXX
gnuherds.org/View_Qualifications.php?EntityId=XXX
/resume?id=XXX
Davi
- Re: If it is possible, avoid complexity, (continued)
- Re: If it is possible, avoid complexity, Klaus Weiss, 2007/04/23
- Re: If it is possible, avoid complexity, Victor Engmark, 2007/04/23
- Re: If it is possible, avoid complexity, Davi Leal, 2007/04/23
- Re: If it is possible, avoid complexity, Victor Engmark, 2007/04/23
- Re: Microformats and logical URLs -- mod_rewrite, Davi Leal, 2007/04/23
- Re: Microformats and logical URLs -- mod_rewrite, Victor Engmark, 2007/04/24
- Re: Microformats and logical URLs -- mod_rewrite, Davi Leal, 2007/04/25
- Re: Microformats and logical URLs -- mod_rewrite, Victor Engmark, 2007/04/25
- Re: Microformats and logical URLs -- mod_rewrite, Davi Leal, 2007/04/25
- Re: Microformats and logical URLs -- mod_rewrite, Victor Engmark, 2007/04/25
- Re: Microformats and logical URLs -- mod_rewrite,
Davi Leal <=
- Re: Microformats and logical URLs -- mod_rewrite, Victor Engmark, 2007/04/25
- Re: [Roadmap -> Hackers' Guide] [e-Voting -> FAQ], Davi Leal, 2007/04/25
- Re: Microformats and logical URLs -- mod_rewrite, Davi Leal, 2007/04/25
- Re: Microformats and logical URLs -- mod_rewrite, Victor Engmark, 2007/04/26
- Re: Microformats and logical URLs -- mod_rewrite, Davi Leal, 2007/04/26
- Re: Microformats and logical URLs -- mod_rewrite, Davi Leal, 2007/04/26
- Re: Microformats and logical URLs -- mod_rewrite, Victor Engmark, 2007/04/26