Share notes, thoughts, links, outline, and whitepaper elements.
For data visualization, I’d like some defaults sitting on greater functionality. It might make sense to run on an [R] back end like Visibility Analytics. The trick would be to know what was submitted, so as to know how to draw it. In particular I’m thinking about text analytics and graphs, thought things like timelines, trends and confidence intervals would all be good things to have as requirements.
There should also be a “browser mode”, a “presentation mode” and a “report mode”.
Ethnomethedological study on building a generalizable data entry/visualization system.
Requirements change. Code should be able to handle that. What does that mean?
- Realtime form designer, with automatic connection to DB back end
- Scripting middleware, with separate editors for DB and scripting(jython, in our case)
- Report/Data visualization (Intermingled text and graphics). Reports, quad charts, slide shows, etc.
- Get/put post handling with roles. Before the data shows up, login has to occur.
- HTML-like(?) syntax to store forms and reports. Should be able to point at data sources within document
- Legacy (I’m looking at you IE7) support
- Ability for a novice user to produce something useful with little or no training.
- Tool-enforced ontology(s)? If I write a report that calls something a server, should I have to define it? That way the next person to store something in the DB will know whether the table means a computer or a waiter.
- Rethink help, from the perspective that no one will ever write documentation again ever.
- Welty, Charles J. “Usage of and satisfaction with online help vs. search engines for aid in software use.” Proceedings of the 29th ACM international conference on Design of communication. ACM, 2011.
- Matejka, Justin, Tovi Grossman, and George Fitzmaurice. “Ambient help.”Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. ACM, 2011.
- So maybe the help system should be user-driven. We could build a context-tracking system that is aware of several things
- The actions that got the user to a point.
- Success or failure (Success = moving to a new task within x seconds, failure means taking more than that. This may change as the user gains experience
- The behavior of the developers (Stand in for experts). This system could be trained as it’s developed
- Branches that are nearby to a “fail” state that others had success with
- Menus and menu items organized by usage. A frequent menu item could be either/both higher and brighter
- Stackoverflow-style forums (moderated?) that can be attached to any component. Mousing over brings up a tooltip. Clicking in the tooltip brings up a window with the whole thread. The forums should be tied into the context system
- High-success users can be tagged as experts. An in-system messaging system could have help questions and responses added into the dynamic help.
- Chilana, Parmit K., Andrew J. Ko, and Jacob O. Wobbrock. “LemonAid: selection-based crowdsourced contextual help for web applications.”Proceedings of the 2012 ACM annual conference on Human Factors in Computing Systems. ACM, 2012.
- Mouse tracking as an analog for eye tracking.
- Alerts. We know that what we’ve tried hasn’t worked.
- Ambient alerts? Rattenbury, Tye, et al. “A peripheral display toolkit.” (2003).
- Collaborative alerts? Sen, Shilad, et al. “FeedMe: a collaborative alert filtering system.” Proceedings of the 2006 20th anniversary conference on Computer supported cooperative work. ACM, 2006.
- Is this just a variation on business process management? Medina-Mora, Raul, et al. “The action workflow approach to workflow management technology.” Proceedings of the 1992 ACM conference on Computer-supported cooperative work. ACM, 1992.