Centralizing (1a)

[Michael Allan]

Thomas von der Elbe wrote:
> Wow, this is so beautiful!
> 
> Once it is in the wiki too, I think, it will make the navigation finally 
> very clear and easy to understand. :-)
> 
> And I like the new naming very much. Especially "Voting" and "Results". 
> Again more clarity.//

It's coming together!  I only wish we could do it faster.  (Thanks for
helping with the layout.)

I'm upgrading the server to MediaWiki 1.15 and adding some extensions.
We'll be able to have a custom top-left image for each area (city,
state, etc).  Also a custom display title for the various
area-associated pages.  So neighbourhood, street, district, poll and
position pages needn't include the area name in the page title.  I
imagine subpages like this:

  Smithville_NY/Main_Street,
  Jonestown_ON/Main_Street
  Tor/Main_Street

Those street pages could all appear as just "Main Street".  Likewise,
these districts could all appear as just "Ward 5":

  Tor/Ward_5
  Ottawa/Ward_5

And these electoral polls, all "Councillor for Ward 5":

  P/w5cTor
  P/w5cOtt

Then, with the area names removed from the title, we don't have to
worry about hierarchical naming schemes (big headache).

> > Because it sits in the wiki, it'll be cross-project.  So the core will
> > become kind of rigid.  But pollservers can float their own doo-dads
> > around it, like I did with Area/Scheme/District (soon to be removed).
> >   
> 
> I think, some voting-tools will want to link from the wiki to their 
> tools already when you click on a specific poll in a list of polls from 
> a given area, because they have their own navigation for inside their 
> polls. And since our new navigation is only for inside a poll too, they 
> wouldnt even have to see it. For that it would be good, to have (in the 
> list of polls) a possibility to describe the polls in more detail. (What 
> right now happens in **our* *poll-page, which is actually more a list of 
> **our* *positions.) What do you think?

I think I see the problem.  It's esp. difficult, because different
wiki users are going to see the same navigation tool (and other page
content), regardless of what pollserver they prefer to use.  If there
is disagreement about the design of that tool, we can accomodate it by
allowing the page content to vary from area to area, or even from page
to page.  (At the risk of anarchy, we're letting the users take
ultimate responsibility for a large portion of the UI.  Ideally we'd
give them a choice of which pollwiki/streetwiki to use, but that's
probably not feasible except by the extremity of forking.)

Possible solutions:

(1) Somebody might code a MediaWiki extension for "preference display"
(along the lines of "preference routing" ^[1]).  But I think it would
be tricky.  MediaWiki caches pages aggressively, so you'd probably
need Javascript to get around that, letting the client do the actual
alteration of content.

(2) But then, why not go further and use greasemonkey?  We can put
preference display *entirely* on the client-side (and routing too).
Then it will apply not only for the wiki, but also for other sites and
services that are displayed in the user's browser.

(3) Or go whole-hog and move the entire pollserver to the client side
(your meta-tool), with personalized vote filtering and everthing else.

Maybe (2) and (3) are the future.  But we need a simple solution to
get us started.  So maybe:

(0) Do something about that position list in the poll pages, since
that's the particular problem.  Maybe there's a way of making it
pollserver-agnostic?  Or maybe keep it as it's intended to be
(top-ranked candidates), but offer an alternative position chooser (or
whatever) alongside.  (We'll have lots of room in those poll pages.)

[1] http://groups.google.com/group/votorola/t/b6869e8f54698655

-- 
Michael Allan

Toronto, +1 647-436-4521
http://zelea.com/