(BUG) Operation of harvest kick mechanism is unclear
mike at zelea.com
Thu Nov 29 23:10:35 EST 2012
> I agree that we should have a placeholder, but the problem is still
> how to model the update function so people get what they want (and
> understand how it works). We already have a (dumb) tooltip.
Whoops, now I see it, "find new posts". Right, it's dumb in the sense
of being static text. I think all it needs is a context variable:
Find new posts for candidate C's group
This is part of what you explained to Thomas. Maybe we can make the
rest self-explanatory. E.g. if the harvest succeeds quickly and a new
post appears on stage, then maybe all that's needed here is to make
the entrance dramatic enough so the user understands, "I press this
button and this happens."
Otherwise, if the harvest fails, or is delayed, then maybe the kicker
could offer an explanation, "Sorry! I tried to find new posts for
candidate C's group, but I ran into this problem..."
Here's where it could explain, for example, that C needs to specify
the group's forum (or forums) on his position page.
> Hey guys,
> Michael Allan wrote:
> > Thomas von der Elbe said (in the other thread):
> > > Btw, why is my latest post (diff) in the home-page-thread not shown
> > > in the talk-track. Wasn't metagov not being harvested too?
> > http://metagovernment.org/pipermail/start_metagovernment.org/2012-November/0
> > 05207.html First you have to make the kick button appear in the talk track.
> > Currently it looks like a '?'. (I think you need to be at a position
> > in votespace, e.g. by navigating in the vote track.) I'm not sure if
> > you need to be at a *particular* position, but I think so. I think it
> > harvests messages for a single group (candidate and immediate voters).
> > Then you press it.
> > Probably the fix is to make the button more self-explanatory.
> > (1) Maybe it should have something like a tooltip.
> > Harvest messages for candidate C's group
> > /
> > -------- ?
> > (2) Maybe also enabled/disabled state instead of being added/removed,
> > because that transition can be disorienting:
> > -------- no kick button
> > -------- ? button appears
> > Wheras this one is more informative:
> > -------- - button disabled
> > -------- ? button enabled
> > (3) Maybe also a special tooltip for the disabled state:
> > Cannot harvest messages, no group selected
> > /
> > -------- -
> > What do you guys think?
> I agree that we should have a placeholder, but the problem is still how to
> model the update function so people get what they want (and understand how it
> works). We already have a (dumb) tooltip.
> Preamble: The button-solution still hides the main problem, which is that we
> need user interaction to trigger updates. Since we have no way found yet to
> detect when new messages are posted somewhere, we have to rely on the user to
> tell us. (Forums are cut off from us)
> 1) Currently we have come to the conclusion to model the discourse depending
> on candidate forums, so you are expected to post to forums of your candidate.
> In your case you are end-candidate (special case), so you define it for your
> Forums are currently not configured there, you can see how to set the Metagov-
> list as a forum for a position here:
> 2) Once it is set there you can hit the '?' on your page and it will look for
> new messages in the metagov archive.
> Note that currently this update-call does not cascade down the tree, so it is
> only the forums of your candidate which are triggered. Not your candidate's
> candidate ones, etc.
> Mike pointed out that harvesting forums set on your own page is not really the
> point, as you are trying to discuss with covoters and candidate and not in
> some other forums. So if you were voter for e.g. Ed, then only forums on Ed's
> position are updated when you hit '?' on your page, not yours. But you define
> the forums for the '?' button on your voters page.
> We know that this is not very intuitive, but we have to find a way to get
> clear update events without triggering all kind of forum updates for the whole
> tree and we can only do so by defining clearly which forums are used for
> discussion. Do you have any ideas of how to model that discourse update
> better? I have asked myself if we can make it implicit, e.g. just by selecting
> posts in the talk-track on a position.
More information about the Votorola