Live Fedora start page proposal

Donald Fischer dff at redhat.com
Tue Aug 28 14:53:05 UTC 2007


On 8/28/07, seth vidal <skvidal at fedoraproject.org> wrote:
> > Here's why I think this simple change makes sense:
> >
> >  * More useful to users.  The vast majority of the time when Fedora
> > users are launching a new browser, they're looking to do something on
> > the web, not to read the operating system release notes.  Thus, we've
> > proposed to put search front-and-center.
>
> Isn't the search already on the search bar that defaults in firefox?

There is also search there, yes.  This proposal doesn't consider
modifying that in any way, but rather adding a search box to the start
page that has the mentioned Fedora tweaks.

> > To try this out, there's only one small change required in the
> > distribution itself, which is to swap the default URL in the browser
> > configuration to http://start.fedoraproject.org.  This switch is a
> > time-sensitive issue with respect to Test2, since we'd like to field
> > this in at least one and ideally two test releases before deciding to
> > release it in a final Fedora version.
>
> I'm not trying to be snide but is there a reason you waited until the
> eleventh-hour before test2 went out to ask about this?

No ulterior motive here; getting our ducks in a row and the prototype
page set up took longer than we anticipated but I wanted to push to
make the deadline to try it in Test2 rather than delaying to Test3.

> >  * Internationalization of the hosted start page and search results
> > pages is certainly doable, just as with the local release notes.
>
> doable, but not done?

Not done yet, but there is minimal text to be translated on the start
page itself and the third party search services that we'd build on are
widely internationalized.  We'd use the regular Fedora documentation
i18n workflow for the necessary translations, I suppose.

> >  * Red Hat will supply the server infrastructure and bandwidth
> > required for this project.
>
> Red Hat will? or will fedora's infrastructure provide it? Who will
> control it? What, if any, software is required server-side to facilitate
> this?

Red Hat will pay for the incremental server and bandwidth so that it's
not an additional cost burden competing with existing Fedora project
expenses.  Open to discussing the governance model the server itself,
presumably we could handle it like other Fedora infrastructure
services.  At present it's just a static web page and a few images; in
the future we anticipate also having a hosted results page that would
be a simple JSP.

> >  * For users without Internet connectivity, we could do something
> > fancy to avoid showing an error message, though that would be more
> > than upstream Firefox does.  In fact we have prototyped modifications
> > to Firefox to achieve this, but our conclusion was that the additional
> > complexity is not justified.  Using a web browser without access to
> > the web seems to be a corner case and one in which a warning message
> > is appropriate!  In the offline case, local release notes would still
> > be available from the default bookmarks toolbar.  Tuning offline
> > behavior is an area that we could look at further in conjunction with
> > the community.
>
> It's not just w/o internet access. It is with limited/controlled
> internet access, too. Remember, it's not just the possibility of the
> page not loading, it's the possibility of the whole thing stalling out
> waiting 2 minutes or more for a dns resolution that ISN'T going to come.

I hear you, definitely think we could look at doing various things
here and the online desktop team has the resources to do so.  When we
tried out some workarounds for this issue, the general feeling was
that we might be trying to be too smart for our own good (e.g. how
long should you wait before you decide that the user is offline vs.
has a slow connection?)  Fielding in a test release sooner than later
would give us some real data about what this issue actually looks like
in the field.

thanks,

don




More information about the advisory-board mailing list