User:Alex.rollin-GmailCom/Crossforum
This documentation is part of the Votorola system architecture as seen from a novice perspective. The idea is that I make notes in this page about how I see things and someone else hopefully corrects me. YMMV.
Contents |
Crossforum UI Purpose
Crossforum, or the Crossforum UI, exists to connect a user to all the discussions related to the polls that a user/voter is interested in.
Crossforum Components
- Framefeeder application
- collects information from other services, processes it, and stores it in a database
- Framefeeder database
- Stores the information
- Framefeeder Service
- Responds to requests from the the Crossforum UI for data
- Crossforum UI
- Displays the framefeeder service data based on user preferences
Crossforum UI Assumptions and Prototype Requirements
Long term
- A user of the UI will be associated with a cluster of pollservers and a pollwiki.
- A user will have an account on the pollwiki and at least one pollserver
- The pollwiki will be used to store user information related to discussions.
- The difference bridge is THE place to track action related to polls and positions.
- Framefeeder service will give chunks of trees for rendering
Short Term Prototype Assumptions
- Voting will continue to take place on the pollserver, since it already exists
- We will use semweb properties to indicate discussion data sources
- Parsing the metagov list for difference bridge links
What makes the Crossforum UI so important
1. new post in discussion 2. new position drafted or an existing one changed or a diff merged 3. new vote cast or an existing one changed (maybe 4. new user registration) (maybe 5. these users are online: ....) (maybe 6. these users are having a chat here)
Crossforum started as a discussion and then Mike made a diagram.
Mike's diagram:
Mor of Mike's docs are here:
http://reluk.ca/project/votorola/s/gwt/scene/
Another early idea was Thomas' meta tool: http://obsidian.reluk.ca/w/User:ThomasvonderElbe_GmxDe/Meta-Tool
This diagram shows an interface that is receiving information that users can read to keep on on relevant discussions.
Topic area. This is a place to put some semweb stuff so users can find my documentation.
Here is a version of where the Crossforum UI sites in relation to the rest of the Votorola system https://docs1.google.com/drawings/edit?id=1F1r9q03QPnIwjIDqtDrsCWOruIRri-BRtQArn4aSmd8
This is editable by those with a Google Account who would like to correct it.
The frame reader scripts (dubbed scripts by me) are an set of scripts that could form an application. The frame reader application?
Anyways, those scripts do a bunch of stuff.
Frame Feeder Application
The primary purpose of the frame read application is to gather discussion items together and place them into the Frame Reader Database.
The Frame Reader Application collects a bunch of information to do this:
- Collect information from the pollwiki
Needs an index of polls Doesn't need to read the text of positions.
Map can be single poll or poll space Scope of events. Hope for something happening based on interest. Discussion focused. Drill down into the map. See things. Go into a particular poll. See the poll. See the tree. Have a sense of the activity going on aroudn the event space, poll or poll space.
See co-voters. See what's going on over there. "They are reformatting their document" someone might say. If you are not familiar, it'll give you a sense of what's happening. You may not know it's a poll, but you click in and see trees. See a message pop into th node on the tree. Somebody said somethign about the text tehy are working on. You are taken to the forum and there's a discussion. You can see, and you might want to join.
The discussions that are scraped are coming from the difference bridge. There are no other discussions besides those in textual differences within text within a tree. Could provide overview of areas and pollwikis. Difference bridges are associated with a pollwiki and a cluster of pollservers. The biggest space is the area or pollwiki. Currently pollwiki would be best. So multiple areas are possible. The cross forum app should work with any pollwiki cluster.
The default show is "who's talking about what in the world"
Once we have a distributed system then this device will work with any cluster of poll servers and a single pollwiki. In our case it is interested in treed votes, so itll connect to the pollwiki pollserver and difference bridge. It integrates the structure of voting and discussion acitvity together into a single view.
Voting through it is is a minor aspect. Shifting a vote is a major thing. You are always in communication with other people. Only some people are drafters, and they would be drafting too, but they are not the core use case for drafting.
If you are not a drafter there isn't a lot for you to do. Later functions. What should you be interested in voting for? Different view for that.
The core part of this is the transmission of the discussion media into the discussion efforts. Without that we would have a system of communicative action with no connection between the communication and the action.
We are centering. You are not forced to go into the pollserver to post your opinions.
Allow people to pick their own forums they talk.
The difference bridge is only the link.
The metagov list as a mailman app. The difference bridge has a url The scraper will go to those lists and search out threads with difference bridge links that are posted to them and parsde those to populate the event map space visualization.
A semweb property in the position statement of a person that they are discussing something somewhere. The difference bridge can discover on it's own through inbound urls, but it will need methods for parsing each site/cms/db structure.
We are going to invite people to link in networks because it is in their interest to publicize them.
You have to be able to get a url for that message in order to be able to visit the discussion list or unique url where that message is posted. For facebook this would be theunique idea of a wall post with the comments inside it for others to be able to visit and participate.
They can put their information into their registration with their email addresses and account information for data sources. Frame feeder. Running on it's own server. It's a service.
Service. Runs on a computer. Provides a news feed. Provides these events that are of interest to cross forum theater. Pollwiki page updates. Difference bridge outputs. Vote changes.
Cross forum theater app subscribes to fame feeder service. Frame feeder service inturn has a mail server. Has an account. Frame feeder has an email address. It subscribes to all themailing lists that it has to. Scaled down to a cluster because of the volume of information. It has a parser engine. It will scan them for difference bridge pastes. So it knows they are talking about relevance to the issue. Then that message becomes a message of interest. All it has to do is parse it, clip it down to a snippet, archive that, associate it with a poll and link to metadata, and then that's the feed that comes off it. Instead of forcing them into a single discussion you let them talk anywhere in the world. It can subscribe to chat networks as well. IRC.
Users will want
Don't need to see the map projector.
Tree Perusal
- Orient naturally, with leaves at top.
- Show the location of the navigation cursor in the context of nearby nodes. Show at least one candidate and her immediate voters. A candidate may have up to 20 immediate voters (more in fact, but the mosquito voters need not be shown).
c) Define graphically how to shift the cursor and the context as
the user navigates from node to node.
d) Put the users to work and play. For example, you might depend
on them to work out the details of the tree's appearance
themselves, especially where these details would serve as aids
for orientation. So the local appearance (shape, colour,
texture, decorations and so forth) in the vicinity of each node
might be chosen by the node's user, while the general visual
parameters for the entire tree and its background are chosen by
the root candidate. You would therefore have to define:
i) General typology of all such customizations
ii) Specific variations of each
iii) How the renderings join or grade between nodes
e) Provide a larger sense of context. Where am I in this tree?
Which tree is this?
f) Render with typical 2D graphics primitives. (I'm not sure
exactly which will be available, yet.)
g) Be displayable on a typical smartphone, maybe in a simplified
form. Note that for small screens, only 1/2 of the display
area will be available.
h) Decorate nodes (and/or node groups) with additional variable
information. The particular type of information to display
will depend on user choice, so the visual format should be
generalizeable. The data may update sporadically and the
updates may be independent from node to node.
Example of visual format: text and/or embedded images. You
would then define the placement of the visual, its background,
and any dynamic effects associated with the updates.
The default type of information will probably be the intensity
of group discussion (rate of posts) per node group. This might
be shown (for example) as a weighted moving average (numeric)
together with a brief history of temporal variation
(sparkline).
i) Spotlight the action location(s) for the current frame of the
frame sequencer, as planned here:
Define therefore how a node (or nodes, or node groups) may be
temporarily spotlighted in the tree. When multiple nodes are
involved, the spotlighting must be distinguishable between the
two (e.g. colourized). Similar distinguishing markup will be
added to the frame content in the sequencer.
Examples: If the frame summarizes a message that was posted to
a discussion thread, then the poster's node in the tree would
be spotlighted. If the message also contained a diff, then a
second user's node would be spotlighted in a different colour
(say).
