[Sputnik-list] blueprint

[Jérôme Vuarand]

2008/2/7, Yuri Takhteyev <yuri at sims.berkeley.edu>:
> >  I personnally don't like the appearance of the default Sputnik
> >  template, but I must admit it works very well, both in show mode and
> >  edit mode. I still use it for my configuration pages. However as a
> >  basis for custom templates it's maybe too complicated, it took me some
> >  time to understand how everything works.
>
> Can you be more specific?  I don't consider myself much of a designer,
> so I promise to not take visual appearance comments personally!
>
> In regards to the difficulty of figuring it out, what would have made
> it easier?  E.g., would it help to divide the templates between
> different pages, e.g., keep all the "advanced" stuff (RSS, edit UI,
> etc.) in a different node.  Or is it a matter of figuring out how
> Cosmo templates work?  Would the new documentation
> (http://sputnik.freewisdom.org/cosmo/) have helped ?

Actually I didn't ran into Cosmo when modifying the template but only
later when I added support for a "flat" nav bar, but the link is
welcome.

The problem I think comes from the _templates page, which is big and
contains many things, maybe too much. The way path "MAIN -> $nav_bar
-> sputnik sources -> NAV_BAR -> $do_sections -> _navigation" for
example is rather deep, for a feature that I consider to be an
example/tutorial of features the user can add.

Maybe that's the lack of documentation, maybe it's because I do most
of my web admin while watching television :-)

Another point that was not very clear is the Prototype system. I would
have appreciated that links to the default prototypes were in the
default navigation bar. For example on my site I use Sputnik more like
a CMS than an open wiki, and I had to modify the @Root template before
anything else just to make sure I'm the only one with the rights to
create a new page. Categories are another matter that I still have to
discover.

> >  On the navigation bar subject, I made changes to my sputnik copy to
> >  have a flat navigation bar with all sub-sections displayed all the
> >  time. I think it's more common, and easier to use. This allows quicker
>
> This makes sense for a vertical navigation bar.  I'll add a config
> variable for this: this one is actually quite easy.  I assume that
> making the menu display vertically wasn't hard, right?

Actually, as said above, I thought at first I would have been able to
change that only with data files, until I discovered the link between
$nav_bar and the NAV_BAR template is hardcoded.

> >  navigation, and with a cascaded menu with javascript to close by
> >  defaults sections other than the current one it doesn't take much more
> >  space. On my website I don't have many sections/subsections yet, so I
>
> >  navigation data). I can share the code (it may take some time for me
> >  to setup a clean install to make a diff though).
>
> If at some later point you decide to upgrade, then send me the new diff.
>
> >  About navbar-less sites, I think that a wiki with a sufficiently dense
> >  network of internal links maybe very usable even without a navigation
> >  bar. Also optionnal may mean hidden by default, but still accessible
> >  with a client-side script.
>
> Or, simpler, there could be a flag to turn it on or off.  The issue is
> the following: if you install a wiki and it has a menu bar, and you
> don't want one, you would presumably ask: "How do I get rid of it?"
> and find the solution if it exists and is documented.  If you install
> a wiki that doesn't seem to have a menu bar and you decide you want
> one, you might just assume that there is no support for that and give
> up.  No?

That's true, without a doubt. You can apply that argument to any
advanced feature though. However I agree that nav bar is essential
enough to be present by default. Having it fully data-driven would
make it a good example for customization, on the other hand having a
small base of static features helps to stabilize the global
architecture while experimenting with templates.