I've redesigned squeak.org
and I think all the problems are solved. The problems were a
doubling menu bar; an extraneous navbar; Altitude components
that didn't jibe with the Bootstrap layout; and, 24-char
tokens instead of regular looking URIs (i.e. /community or
/blogs).
The way the Altitude's examples are laid out uses composition
and a class that acts as a frame with a navbar. The frame
allows other classes/components to be swapped out of an ivar
called #current with the navbar.
I did away with that and replaced composition with
inheritance. Now there is an abstract superclass (i.e.
SQAbstractSuperclass) and every page with content is a
subclass with a #renderConentOn: method. The navbar supplied
by Bootstrap is created by the abstract superclass. All links
are hyperlinks (i.e. all "html a href:" and no "html a
navigate:", "html a callback:", or "html a linkTo:").
So the superclass creates the menu. All the content classes
have #renderContentOn:. The only remaining thing is to list
all the tokens you'll use for URIs in
SQSqueakApplication>>#initializeLocator.
initializeLocator
locator
at: ALPath root
put: SQHomePage new asResource.
locator at: ALPath / 'license'
put: SQLicensePage new asResource.
locator at: ALPath / 'blogs'
put: SQBlogsPage new asResource.
locator at: ALPath / 'docs'
put: SQDocumentationPage new asResource.
locator at: ALPath / 'community'
put: SQMailingListsPage new asResource.
locator at: ALPath / 'devlinks'
put: SQDeveloperLinksPage new asResource.
locator at: ALPath / 'projects'
put: SQProjectLinksPage new asResource.
The result is a website using standard looking URIs that is
dead easy to make. It won't win any prizes, but it fits the
spec and is simple as a pin. Altitude is nothing of not
versatile. There are color, positioning, etc. details so it'll
be a few days before I deploy the new version.
Chris
Sounds good. In addition:
IMHO we should try to match the existing URLs unless the new
structure is too different in places.
This would mean e.g. the community page should live at
/Community not /community, documentation at /Documentation not
/docs etc. External deep links would continue to work, which I
generally consider a Good Thing.
Alternatively, we could add redirects from the old locations
to their new home.
And it would be a good idea to monitor the error log to find
out about old URLs in use. Altitude does create access logs and
error logs, I assume? Or would that be handled by Apache?
Also, the error page should be customized, currently it is
not too helpful:
If it instead displayed a site map (list of all major pages),
people arriving from dead URLs could still quickly jump to where
they would want to go. Also, it would be cool to have a nice
graphic, e.g.:
Those are all good ideas. And I think they'll round out the user
experience in important ways. Added to which they're simple to do.
The only thing is that I think they're a bit ahead of the curve.
These ideas to me are closer to actual deployment. I'm going to
complete the basic site and then I'll add these things. I like the
picture for an error message.
Especially when it points to a topic of active discussion, NetNameResolver :)