[MG] Ease of entry

[Michael Allan]

Thomas von der Elbe wrote:
> >> Only, I would immidiatly link to the creation page, if "My" is
> >> clicked by a user without an own draft.
> >
> > So sometimes 'My' would behave as a modal switch (as originally
> > suggested), and at other times as a direct link?
> 
> Yes, because in the latter case it cannot behave like a switch, because 
> there is nothing to switch to yet.

It could still switch modes.  It would go into 'My' mode, enabling the
draft link and so forth, exactly as it normally does.

But maybe it's moot.  In practice, the footing script won't always
*know* if you have a draft, or not, till after you click on the link.
Then you're redirected through the server, which may require you to
login so that it can discover who you are (see original post), and
complete the request.

> You didnt answer to the following:
> >
> >> ... And concerning the issue of space: How if we had a
> >> collapsable menue like in the theatre map? This could then be
> >> really big, covering the whole left wiki menue. Wouldnt that be
> >> great?
> 
> I'm really excited about it.

It might be a good idea if we were stuck, at some point.  It would buy
us more space, at the cost of added complexity to access the controls
vs. the sidebar (or vice versa).  But for now, I think we have enough
space to do what's needed.

People may want to put more stuff into these draft pages in future,
but I think they'll be fighting an uphill battle.  The rationale of
the architecture demands that functional additions to the component
media - drafting, voting, discussion - be deployed externally in
common bridges, umbrellas, what have you that impact on those media
with a light touch.  Every exception to that rule fights against the
openness of the architecture by making it harder to add new
components, such as alternative drafting, voting and discussion tools.
It's this rationale that gave us the difference bridge in the first
place, and later crossforum theatre.

Imagine that an instance of the theatre app running in your phone,
say, could somehow be "aware" that you're viewing a draft page in your
Web browser on the desktop.  It would then go into a supporting mode
in which it provided all the navigation aids you needed, but which
MediaWiki (or whatever) could not provide.  It might even awaken a
copy of itself on the desktop, or in the browser, if necessary.
Something like that might be the future.  Plus apps that talk to each
other as they pass on the street.  That's all part and parcel of
deploying in the public sphere.

To save time, I think I'll add a draft creation link, but defer the
automatic creation.  Instead, I'll write step by step instructions for
manual creation.  That should be enough to bounce the problem back to
the political side of the court.  Ease of entry is one thing, but we
also need entrants.  (And then I can rejoin C in the theatre app.)

> >> One more idea: If you click on a user, the footing gets fixed. To
> >> unfix it you have to click this user again. Additionally I'd like
> >> to be able to click on the orininal user to unfix the footings.
> >
> > http://metagovernment.org/wiki/User:Conseo/draft
> >
> > Currently if you click by mistake, say out of curiosity, then you can
> > always click again to undo the result.
> 
> I like this and want to keep it.
> 
> >   It'll be hard to remain
> > consistent with that behaviour if we allow clicking on the origin
> > (4c.).  What happens when we click there first, like just after the
> > page loads?
> 
> After this page loads, no footing is fixed. So clicking on 4c. doesnt 
> "unfix" anything. So nothing happens. Only if a footing is fixed, you 
> can return to the original state by clicking on 4c. or on the other 
> user. You can understand it as: clicking on 4c. shows the footings of 
> 4c. in 4c. which equals: no footings. :-)

Then you can't click twice to undo an off-click on the origin (4c.).
The footprint vanishes, and clicking again does not bring it back. (!)
Logically, there's no way to make it behave consistently except by
keeping it non-clickable.  That's why I think the solution is to make
it *look* non-clickable.  If I'd done that in the first place, you
would never have noticed. ;-)

-- 
Michael Allan

Toronto, +1 416-699-9528
http://zelea.com/



Originally posted to the mailing list of the Metagovernment Project:
http://metagovernment.org/mailman/listinfo/start_metagovernment.org