Re: navigation menu for documents

For a very long time I have thought that it would be useful to have some
sort of navigation menu for the docs similar to what you get with
doxygen. I had a brief look at it today but I am lost for a place to
start with it. Does anyone sufficiently understand how the docs work to
be able to say how one might achieve such a thing? Navigating the docs
requires far too much use of the back button and up links, IMNSHO. A
menu frame would make them far more usable.

cheers

andrew

Hi,

Le 14 juil. 09 à 22:17, Andrew Dunstan a écrit :
> For a very long time I have thought that it would be useful to have
> some sort of navigation menu for the docs

Oh yes, pretty please :)

> Navigating the docs requires far too much use of the back button and
> up links, IMNSHO. A menu frame would make them far more usable.

No, please, no frame! Really...

What I'm thinking about is to extend current "breadcumb" at the top of
the page to include chapter, section, subsection. So that for exemple
the following page:
http://www.postgresql.org/docs/8.3/interactive/datatype-geometric.html#AEN5480

Would have at its top:
Home → Documentation → Manuals → PostgreSQL 8.3 → Data Types
→ Geometric Types → Points

Well the last entry, Points, I'm not so sure about. But I think you
get the idea.

Regards,
--
dim

Dimitri Fontaine wrote:
> Hi,
>
> Le 14 juil. 09 à 22:17, Andrew Dunstan a écrit :
>> For a very long time I have thought that it would be useful to have
>> some sort of navigation menu for the docs
>
> Oh yes, pretty please :)
>
>> Navigating the docs requires far too much use of the back button and
>> up links, IMNSHO. A menu frame would make them far more usable.
>
> No, please, no frame! Really...

Yes, really. What you suggest here is just not adequate, IMNSHO. I don't
want to have to scroll to the top or bottom of the page to get
navigation, and I want to be able to see the navigation and go where I
want directly.

I know some people have a violent aversion to frames, but I don't. They
have legitimate uses.

>
> What I'm thinking about is to extend current "breadcumb" at the top of
> the page to include chapter, section, subsection. So that for exemple
> the following page:
>
> http://www.postgresql.org/docs/8.3/interactive/datatype-geometric.html#AEN5480
>
>
> Would have at its top:
> Home → Documentation → Manuals → PostgreSQL 8.3 → Data Types →
> Geometric Types → Points
>
> Well the last entry, Points, I'm not so sure about. But I think you
> get the idea.
>

Compared with what things like doxygen or webhelp give you it's not
remotely what I want.

cheers

andrew

Le 15 juil. 09 à 00:21, Andrew Dunstan a écrit :
> Yes, really. What you suggest here is just not adequate, IMNSHO. I
> don't want to have to scroll to the top or bottom of the page to get
> navigation, and I want to be able to see the navigation and go where
> I want directly.

Ok we don't share the same needs here, and I get what you're after.

> I know some people have a violent aversion to frames, but I don't.
> They have legitimate uses.

Agreed, but even when they do, I find I'm not shortening the time
needed to find my link. Here the navigation frame will either contain
too much entries to be useful (you'll need to scroll around), or will
have some expand/collapse tree that will make you click way to much to
be proficient in your search. IMO.

> Compared with what things like doxygen or webhelp give you it's not
> remotely what I want.

Ok.

Regards,
--
dim

Andrew Dunstan wrote:
>
> Yes, really. What you suggest here is just not adequate, IMNSHO. I don't
> want to have to scroll to the top or bottom of the page to get
> navigation, and I want to be able to see the navigation and go where I
> want directly.

Are you talking about the online manuals, or something else here?

--
Richard Huxton
Archonet Ltd

Richard Huxton wrote:
> Andrew Dunstan wrote:
>>
>> Yes, really. What you suggest here is just not adequate, IMNSHO. I
>> don't want to have to scroll to the top or bottom of the page to get
>> navigation, and I want to be able to see the navigation and go where
>> I want directly.
>
> Are you talking about the online manuals, or something else here?
>

I don't care if we don't provide this for the online manuals on
postgresql.org - I'm quite happy to install it on my own server if
necessary. But I am talking about the HTML docs that come from our /doc
directory. And I bet if we had the option of better navigation, our
online users would want us to provide it.

cheers

andrew

Andrew Dunstan wrote:
>
>
> Richard Huxton wrote:
>> Andrew Dunstan wrote:
>>>
>>> Yes, really. What you suggest here is just not adequate, IMNSHO. I
>>> don't want to have to scroll to the top or bottom of the page to get
>>> navigation, and I want to be able to see the navigation and go where
>>> I want directly.
>>
>> Are you talking about the online manuals, or something else here?
>>
>
> I don't care if we don't provide this for the online manuals on
> postgresql.org - I'm quite happy to install it on my own server if
> necessary. But I am talking about the HTML docs that come from our /doc
> directory. And I bet if we had the option of better navigation, our
> online users would want us to provide it.

Shouldn't be too hard to come up with something reasonable with a little
css. Something only activated if javascript is turned on or some such.
Give me 48 hours and I'll have a play.

--
Richard Huxton
Archonet Ltd

2009/7/15 Andrew Dunstan <andrew(at)dunslane(dot)net>:
> Dimitri Fontaine wrote:
>>
>> What I'm thinking about is to extend current "breadcumb" at the top of the
>> page to include chapter, section, subsection. So that for exemple the
>> following page:
>>
>>  http://www.postgresql.org/docs/8.3/interactive/datatype-geometric.html#AEN5480
>>
>> Would have at its top:
>>  Home → Documentation → Manuals → PostgreSQL 8.3 → Data Types → Geometric
>> Types → Points
>>
> Yes, really. What you suggest here is just not adequate, IMNSHO. I don't
> want to have to scroll to the top or bottom of the page to get navigation,
> and I want to be able to see the navigation and go where I want directly.

Even if we are going to have some kind of tree-based navigation
sidebar beastie, I would be a hearty +1 in favour of doing Dmitri's
breadcrumb suggestion anyway.

I think we can agree that a full breadcrumb/ancestry trail is superior
to "Up/Home", and unlike the sidebar nav idea doesn't require any
fancy scripting shenanigans or possible browser compatibility strife.

>
> Compared with what things like doxygen or webhelp give you it's not remotely
> what I want.

So let's have both.

Cheers,
BJ

Brendan Jurd escribió:
> 2009/7/15 Andrew Dunstan <andrew(at)dunslane(dot)net>:
> > Dimitri Fontaine wrote:

> >> Would have at its top:
> >>  Home → Documentation → Manuals → PostgreSQL 8.3 → Data Types → Geometric
> >> Types → Points
> >>
> > Yes, really. What you suggest here is just not adequate, IMNSHO. I don't
> > want to have to scroll to the top or bottom of the page to get navigation,
> > and I want to be able to see the navigation and go where I want directly.
>
> Even if we are going to have some kind of tree-based navigation
> sidebar beastie, I would be a hearty +1 in favour of doing Dmitri's
> breadcrumb suggestion anyway.

I would agree that the breadcrumbs are a good idea, except that I'm
confused about it including the complete website navigation (instead of
just the docs). IMO the list should be
Home → Data Types → Geometric → Types → Points
(where "Home" points to the top of 8.3 docs).

What happened to the contest for a website redesign anyway?

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Wednesday 15 July 2009 02:27:32 Richard Huxton wrote:
> Andrew Dunstan wrote:
> > Richard Huxton wrote:
> >> Andrew Dunstan wrote:
> >>> Yes, really. What you suggest here is just not adequate, IMNSHO. I
> >>> don't want to have to scroll to the top or bottom of the page to get
> >>> navigation, and I want to be able to see the navigation and go where
> >>> I want directly.
> >>
> >> Are you talking about the online manuals, or something else here?
> >
> > I don't care if we don't provide this for the online manuals on
> > postgresql.org - I'm quite happy to install it on my own server if
> > necessary. But I am talking about the HTML docs that come from our /doc
> > directory. And I bet if we had the option of better navigation, our
> > online users would want us to provide it.
>
> Shouldn't be too hard to come up with something reasonable with a little
> css. Something only activated if javascript is turned on or some such.
> Give me 48 hours and I'll have a play.

You just have to generate the full ToC on every HTML page and then use the
right CSS to make it float where you want it. I suspect that that method
might make the build very slow, though.

All,

>>> For a very long time I have thought that it would be useful to have some
>>> sort of navigation menu for the docs
>>
>> Oh yes, pretty please :)
>>
>>> Navigating the docs requires far too much use of the back button and up
>>> links, IMNSHO. A menu frame would make them far more usable.
>>
>> No, please, no frame! Really...
>
> Yes, really. What you suggest here is just not adequate, IMNSHO. I don't
> want to have to scroll to the top or bottom of the page to get navigation,
> and I want to be able to see the navigation and go where I want directly.
>
> I know some people have a violent aversion to frames, but I don't. They have
> legitimate uses.
Frames are (imho) very difficult to maintain. An easy alternative is
use of floating divs, possibly combined with javascript to make it fit
nicely to the window size. That way, 'breadcrumb' is always visible.
And I believe it is a lot easier to set up and maintain (generate)

Just my 2ct

HTH

Regards,

Serge Fonville

On Jul 14, 2009, at 3:21 PM, Andrew Dunstan wrote:

> Yes, really. What you suggest here is just not adequate, IMNSHO. I
> don't want to have to scroll to the top or bottom of the page to get
> navigation, and I want to be able to see the navigation and go where
> I want directly.

Hey Andrew,

Check out what I've done for the Bricolage documentation:

http://www.bricolagecms.org/docs/devel/api/

I'm using jQuery to pull the proper doc into a div. I'm still noodling
with it, trying to fix encoding issues on Windows, but it's pretty
close to done.

Best,

David

David E. Wheeler wrote:
> On Jul 14, 2009, at 3:21 PM, Andrew Dunstan wrote:
>
>> Yes, really. What you suggest here is just not adequate, IMNSHO. I
>> don't want to have to scroll to the top or bottom of the page to get
>> navigation, and I want to be able to see the navigation and go where
>> I want directly.
>
> Hey Andrew,
>
> Check out what I've done for the Bricolage documentation:
>
> http://www.bricolagecms.org/docs/devel/api/
>
> I'm using jQuery to pull the proper doc into a div. I'm still noodling
> with it, trying to fix encoding issues on Windows, but it's pretty
> close to done.
>
>

Yes, that's nice, it's just the sort of thing I had in mind - if you can
do it with a div instead of frames I'm fine with that.

cheers

andrew

On Jul 16, 2009, at 12:49 PM, Andrew Dunstan wrote:

>> I'm using jQuery to pull the proper doc into a div. I'm still
>> noodling with it, trying to fix encoding issues on Windows, but
>> it's pretty close to done.
>
> Yes, that's nice, it's just the sort of thing I had in mind - if you
> can do it with a div instead of frames I'm fine with that.

Yep. If I can solve the bloody encoding issue with Windows, it'll be
good to go with Pod docs, and easily portable to any HTML-based docs.

Best,

David

OK, if you untar the attached in the docs dir there are a three separate
sets of changes in it. It all functions, but consider it a discussion
point rather than a patch. Presumably we'd need to discuss a patch over
on the docs mailing-list.

1. Fixed navigation
Copy STYLING/stylesheet.css over the existing one and you will have
static navigation links top and bottom of the page.

2. Titles on navigation links.
Run ./STYLING/title_links.pl and it should add title attributes to the
navigation links. This means hovering over the top links gives the title
of the page they will go to. Presumably we could do this directly from
the sgml source, and I think it's probably worthwhile.

With 1+2 I think there's an argument in favour of removing the bottom
navigation - it's only useful if you can't see the top links.

3. Javascript popup menu.
This uses jquery, but that's just for convenience during discussion. You
could rework this without it.
Copy STYLING/*.js and STYLING/menu.inc to the docs dir and then run
./STYLING/include_javascript.pl to include the popup script.
The central "chapter heading" section of the top navigation area should
now be a link that toggles the menu on/off.
The menu could be as simple/complex as you like - this is just what I
hacked together by parsing the TOC on index.html

I've tested it on Firefox, Opera, IE7 and Safari. Realistically, the
only real problem platforms will be IE6 and perhaps iphones.

--
Richard Huxton
Archonet Ltd

On Friday 17 July 2009 15:58:27 Richard Huxton wrote:
> 1. Fixed navigation
> Copy STYLING/stylesheet.css over the existing one and you will have
> static navigation links top and bottom of the page.

Looks good.

> 2. Titles on navigation links.
> Run ./STYLING/title_links.pl and it should add title attributes to the
> navigation links. This means hovering over the top links gives the title
> of the page they will go to. Presumably we could do this directly from
> the sgml source, and I think it's probably worthwhile.

Yes, the DSSSL stylesheet could do that.

> 3. Javascript popup menu.
> This uses jquery, but that's just for convenience during discussion. You
> could rework this without it.
> Copy STYLING/*.js and STYLING/menu.inc to the docs dir and then run
> ./STYLING/include_javascript.pl to include the popup script.
> The central "chapter heading" section of the top navigation area should
> now be a link that toggles the menu on/off.
> The menu could be as simple/complex as you like - this is just what I
> hacked together by parsing the TOC on index.html

This looks very cool, but should probably be implemented via a stylesheet
change instead of some Perl parsing some HTML. :-) I'm not sure if this
actually addresses Andrew's original concern, though.

Peter Eisentraut wrote:
> This looks very cool, but should probably be implemented via a stylesheet
> change instead of some Perl parsing some HTML. :-) I'm not sure if this
> actually addresses Andrew's original concern, though.
>
>

No, it doesn't. David Wheeler's navigation (see upthread) that he uses
for the Bricolage docs does, however.

cheers

andrew

Andrew Dunstan wrote:
>
>
> Peter Eisentraut wrote:
>> This looks very cool, but should probably be implemented via a
>> stylesheet change instead of some Perl parsing some HTML. :-) I'm not
>> sure if this actually addresses Andrew's original concern, though.
>
> No, it doesn't. David Wheeler's navigation (see upthread) that he uses
> for the Bricolage docs does, however.

Ah, if you can change the overall layout then the world is your
shellfish of choice. Would it be possible to include jquery? It's
GPL/MIT dual-licence.

--
Richard Huxton
Archonet Ltd

On Jul 18, 2009, at 9:54 AM, Richard Huxton wrote:

>> No, it doesn't. David Wheeler's navigation (see upthread) that he
>> uses for the Bricolage docs does, however.
>
> Ah, if you can change the overall layout then the world is your
> shellfish of choice. Would it be possible to include jquery? It's
> GPL/MIT dual-licence.

That's what I used for the Bricolage stuff. I still need to fix the
encoding issues on Windows, though…

Best,

David

Peter Eisentraut wrote:
> On Friday 17 July 2009 15:58:27 Richard Huxton wrote:
> > 1. Fixed navigation

> > 2. Titles on navigation links.
>
> Yes, the DSSSL stylesheet could do that.

Since it seems we can get both of these without interfering with
anything else I vote +1 on getting them it.

> > 3. Javascript popup menu.
> > This uses jquery, but that's just for convenience during discussion. You
> > could rework this without it.

This one looks very good to me too -- I like it better than David
Wheeler's, because you just wave it away when you don't need it, saving
screen estate. The only change I'd make it is that the righthand menu
should have only the entries for the current chapter, not all chapters.
But maybe that's just me.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:
> Peter Eisentraut wrote:
>
>> On Friday 17 July 2009 15:58:27 Richard Huxton wrote:
>>
>>> 1. Fixed navigation
>>>
>
>
>>> 2. Titles on navigation links.
>>>
>> Yes, the DSSSL stylesheet could do that.
>>
>
> Since it seems we can get both of these without interfering with
> anything else I vote +1 on getting them it.
>
>
>>> 3. Javascript popup menu.
>>> This uses jquery, but that's just for convenience during discussion. You
>>> could rework this without it.
>>>
>
> This one looks very good to me too -- I like it better than David
> Wheeler's, because you just wave it away when you don't need it, saving
> screen estate. The only change I'd make it is that the righthand menu
> should have only the entries for the current chapter, not all chapters.
> But maybe that's just me.
>
>

This failed miserably to render nicely on several browsers on several
platforms. I'm pretty sure I followed the instructions correctly.

And I disagree about restricting the menu. The whole point is to make it
easy to navigate from one part of the docs to another without having to
go up the tree.

I'm not sure about using third party JS libs that are not BSD licensed,
that's probably a non-starter, although MIT is probably fairly close, IIRC.

cheers

andrew

On Monday 20 July 2009 02:32:01 Alvaro Herrera wrote:
> Peter Eisentraut wrote:
> > On Friday 17 July 2009 15:58:27 Richard Huxton wrote:
> > > 1. Fixed navigation
> > >
> > > 2. Titles on navigation links.
> >
> > Yes, the DSSSL stylesheet could do that.
>
> Since it seems we can get both of these without interfering with
> anything else I vote +1 on getting them it.

For some historical, arbitrary reason the header and footer links are
different:

(Header:)
Prev Fast Backward Fast Forward Next

(Footer:)
Prev Home Next
Title of Prev Title of Next

I would like to combine all these elements in header and footer, so they both
say:

Prev Fast Backward Home Fast Forward Next
TitleP TitleFB TitleFF TitleN

I think this would be much more usable than just the tooltips.

Peter Eisentraut wrote:

> I would like to combine all these elements in header and footer, so they both
> say:
>
> Prev Fast Backward Home Fast Forward Next
> TitleP TitleFB TitleFF TitleN
>
> I think this would be much more usable than just the tooltips.

+1

BTW I was left wondering why the "fast forward" link led to chapter 19
while standing on section 19.4,
http://www.postgresql.org/docs/8.4/static/client-authentication-problems.html

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Did this go anywhere?

Richard Huxton wrote:
> OK, if you untar the attached in the docs dir there are a three
> separate sets of changes in it. It all functions, but consider it a
> discussion point rather than a patch. Presumably we'd need to
> discuss a patch over on the docs mailing-list.
>
> 1. Fixed navigation
> Copy STYLING/stylesheet.css over the existing one and you will have
> static navigation links top and bottom of the page.
>
> 2. Titles on navigation links.
> Run ./STYLING/title_links.pl and it should add title attributes to
> the navigation links. This means hovering over the top links gives
> the title of the page they will go to. Presumably we could do this
> directly from the sgml source, and I think it's probably worthwhile.
>
> With 1+2 I think there's an argument in favour of removing the
> bottom navigation - it's only useful if you can't see the top links.
>
> 3. Javascript popup menu.
> This uses jquery, but that's just for convenience during discussion.
> You could rework this without it.
> Copy STYLING/*.js and STYLING/menu.inc to the docs dir and then run
> ./STYLING/include_javascript.pl to include the popup script.
> The central "chapter heading" section of the top navigation area
> should now be a link that toggles the menu on/off.
> The menu could be as simple/complex as you like - this is just what
> I hacked together by parsing the TOC on index.html

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:
> Did this go anywhere?
>
>

Well, it was sorta nice but what Richard sent wasn't really what I want,
at least, which is more along the lines of the menu David Wheeler uses
for the Bricolage API docs.

cheers

andrew

Andrew Dunstan wrote:
>
>
> Alvaro Herrera wrote:
>> Did this go anywhere?
>
> Well, it was sorta nice but what Richard sent wasn't really what I want,
> at least, which is more along the lines of the menu David Wheeler uses
> for the Bricolage API docs.

Well, if we nail down the details I'm happy to do the grunt-work.

I think #1, #2 (fixed navigation links, titles) are a separate question
and just need to be decided upon by those who feel strongly one way or
t'other.

For the browser, does the following match what you're after, Andrew?
- clicking chapter title opens the browser panel
- panel stays open until you click close icon
- panel contains collapsable tree of chapter/section headings
Alternatively, could just auto-open the browser panel if javascript is
enabled and window is wider than N pixels.

In addition we'll presumably want to meet:
- no external js libraries (or do we care, if we just reference it from
google?)
- navigation is optional, disabling js leaves docs as at present
- works on all reasonable browsers (anything not IE6)
- works online and in downloaded docs (except Windows .chm of course)

--
Richard Huxton
Archonet Ltd

On Sep 29, 2009, at 8:55 AM, Richard Huxton wrote:

> For the browser, does the following match what you're after, Andrew?
> - clicking chapter title opens the browser panel
> - panel stays open until you click close icon
> - panel contains collapsable tree of chapter/section headings
> Alternatively, could just auto-open the browser panel if javascript is
> enabled and window is wider than N pixels.

Why wouldn't the entire TOC be in a collapsed list?

> In addition we'll presumably want to meet:
> - no external js libraries (or do we care, if we just reference it
> from
> google?)

Save yourself the hassle and just bundle jQuery. That's what I've done
for Pod::Site (module that builds the Bricolage API browser).

> - navigation is optional, disabling js leaves docs as at present

As long as there's a way to get the nav back from a link on each doc
page.

> - works on all reasonable browsers (anything not IE6)

+1 (IE6--)

> - works online and in downloaded docs (except Windows .chm of course)

That'd be nice, too.

Best,

David

On Fri, 2009-07-17 at 13:58 +0100, Richard Huxton wrote:
> 2. Titles on navigation links.
> Run ./STYLING/title_links.pl and it should add title attributes to the
> navigation links. This means hovering over the top links gives the title
> of the page they will go to. Presumably we could do this directly from
> the sgml source, and I think it's probably worthwhile.

I have updated the stylesheet to add a title attribute to the header
links. That has about the same effect as your script.

Peter Eisentraut wrote:
> On Fri, 2009-07-17 at 13:58 +0100, Richard Huxton wrote:
>> 2. Titles on navigation links.
>> Run ./STYLING/title_links.pl and it should add title attributes to the
>> navigation links. This means hovering over the top links gives the title
>> of the page they will go to. Presumably we could do this directly from
>> the sgml source, and I think it's probably worthwhile.
>
> I have updated the stylesheet to add a title attribute to the header
> links. That has about the same effect as your script.

Ah, good. My script was only ever intended to demonstrate. That's one
item we can tick off.

--
Richard Huxton
Archonet Ltd

David E. Wheeler wrote:
> On Sep 29, 2009, at 8:55 AM, Richard Huxton wrote:
>
>> For the browser, does the following match what you're after, Andrew?
>> - clicking chapter title opens the browser panel
>> - panel stays open until you click close icon
>> - panel contains collapsable tree of chapter/section headings
>> Alternatively, could just auto-open the browser panel if javascript is
>> enabled and window is wider than N pixels.
>
> Why wouldn't the entire TOC be in a collapsed list?

Permanently on-screen? My only concern there would be for people viewing
on phones etc.

>> In addition we'll presumably want to meet:
>> - no external js libraries (or do we care, if we just reference it from
>> google?)
>
> Save yourself the hassle and just bundle jQuery. That's what I've done
> for Pod::Site (module that builds the Bricolage API browser).

It's MIT licensed (well MIT+GPL) which is BSD compatible, but I don't
know if that's acceptable. It would be easier for me if it could be
bundled and presumably make it easier for other contributors in the
future too.

>> - navigation is optional, disabling js leaves docs as at present
>
> As long as there's a way to get the nav back from a link on each doc page.
>
>> - works on all reasonable browsers (anything not IE6)
>
> +1 (IE6--)
>
>> - works online and in downloaded docs (except Windows .chm of course)
>
> That'd be nice, too.

Offline is crucial as far as I'm concerned.

--
Richard Huxton
Archonet Ltd

On Oct 1, 2009, at 1:12 AM, Richard Huxton wrote:

>> Why wouldn't the entire TOC be in a collapsed list?
>
> Permanently on-screen? My only concern there would be for people
> viewing
> on phones etc.

I have to admit that I'm never looking at the Pg docs on my iPhone.
This is mainly because I use them as a reference while hacking, and
I'm not (yet) hacking PostgreSQL on my phone.

> It's MIT licensed (well MIT+GPL) which is BSD compatible, but I don't
> know if that's acceptable. It would be easier for me if it could be
> bundled and presumably make it easier for other contributors in the
> future too.

Agreed. IIUC, the MIT license is compatible.

Best,

David

David E. Wheeler wrote:
> On Oct 1, 2009, at 1:12 AM, Richard Huxton wrote:
>
>>> Why wouldn't the entire TOC be in a collapsed list?
>>
>> Permanently on-screen? My only concern there would be for people viewing
>> on phones etc.
>
> I have to admit that I'm never looking at the Pg docs on my iPhone. This
> is mainly because I use them as a reference while hacking, and I'm not
> (yet) hacking PostgreSQL on my phone.

Ah, I _do_ look at them on my Nokia N810 when I'm on the train etc.

--
Richard Huxton
Archonet Ltd

On Thu, Oct 1, 2009 at 10:24 AM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> On Oct 1, 2009, at 1:12 AM, Richard Huxton wrote:
>
>>> Why wouldn't the entire TOC be in a collapsed list?
>>
>> Permanently on-screen? My only concern there would be for people viewing
>> on phones etc.
>
> I have to admit that I'm never looking at the Pg docs on my iPhone. This is
> mainly because I use them as a reference while hacking, and I'm not (yet)
> hacking PostgreSQL on my phone.

I probably shouldn't admit this, but I've been known to browse the
*source code* on my iPhone while bored and daydream about some patch
I'm interested in writing.

So +1 from me on anything that is good for mobile users. There's no
limit to what crazy things people will try to do with a phone.

...Robert

Richard Huxton wrote:
> Reworked jquery-based document menu is attached.
>
> Untar will produce bin/ and html/
> cd .../html
> cp /path/to/htmldocs/* .
> ../bin/add_js.pl *html
>
> The contents should be on almost all relevant pages, and:
> - tested on FF3.5, IE7, Opera 9.x
> - expanded if screen width > 800px, closed otherwise
> - contain all page-headings and sub-page headings
> - highlight the current page in the tree
> - provide tooltips for entries that are too wide for the panel
>
> Issues:
> - slow to reload on each page (can be fixed)
> - based on hacked-together perl (this is temporary)
> - layout is perhaps a bit cramped?
>
> This last one is tricky. I can space it better if I can assume as 1280px
> width screen. I can space it better if I have a menu that slides out and
> covers the whole page. Having the menu items wrap onto a second or
> third line just didn't work. At least I couldn't find a way that made it
> clear where the separating line between items was without cluttering the
> whole menu horribly. Settled on not indenting too much, no word-wrap and
> tooltips.
>
> Comments/suggestions/rotten tomatoes?
>

Richard,

First, many thanks for doing this.

I don't see any comments having been made. I guess either everyone has
been busy or they all think it's just fine (or both) :-)

I think you are definitely on the right track. I will use this,
committed or not. But I'd like to see it finished and committed. Can you
fix the 'slow to reload' problem - that is a bit of a pain. I'm not so
worried about the use of perl to add the script calls - you need perl to
build the docs anyway.

It wasn't terribly cramped for me.

I'm not sure everyone will want this. Maybe we need to provide
"with-js-menu" and "without-js-menu" makefile target variants for html.

cheers

andrew