|
This page last changed on Jul 29, 2007 by lauvil@uiuc.edu.
Connect FeatureLens to data model (and to the data scholars need)
Analytics improvements
- allow stemming
- allow aggregation of similar patterns (clusters)
User interface improvements
- UI for new clustering analytics
- Fix UI so that it works when patterns are formed with stemmed terms (in current version, stemmed words can't be found in patterns and highlighting of stemmed words also doesn't work).
- adjustable frame width or allow for sections to be enlarged or popped out into their own window.
- allow combination search+orderby (e.g. search for women, then order by length)
- show more timelines at once (ideally all at once!) + label/highlight of line under cursor; or an initial vis that could permit a discovery driven approach verses a search driven approach.
- remove the checkmarks and instead show the already-visited features with a slightly different color in the list.
- allow for more choices of the settings of docs per line, current version supports 1 and 5, but why not allow for choices of 1-5.
- scrollbar of the text viewer has the up and down buttons at the top and bottom, can we put these beside each other.
- data points in the trend graph could be plotted closer together.
- text in the text viewer should be able to be selected and copied.
- need to be able to link back to document meta data, the document id represented doesn't help indicate the original document/chunk; current db and gui doesn't suffice.
- does it make sense to move the selected blue bar while in the text viewer (when all results are displayed).
- could the dark blue line be more transparent to see colors or at least what column has a color in it?
- do usability test and revise as needed
Bugs
- refresh of the bars in section sometimes leaves a light blue line through the row.
Save State, and History of user actions
Definition of the state of Featurelens
a) to record the state of version 1.0 of Featurelens we need to save at Mininum this:
- collection chosen
- "order by or filter" selection
- search term
- feature(s) selected and color assigned
- location of field of view (i.e. the blue bar that specifies what text goes in the text panel)
- viewing options (not only one in the text pane)
- NOTE: currently the order of operation is irrelevant but that will change (e.g. you should be able to search for a term, then order by some criteria, while currently the search canceled when you order).
b) but to keep the "exact" state you also need:
- window size, so you can return to same resolution, or alert viewer that they may miss something if they do not have enough resolution).
- positions of the scroll bars and # of time the "Next 100" was pressed (i.e. what is really visible in the window).
- all the check marks (of the already visited features)
c) later on, when multiple preprocessed sets of patterns will be available (or custom processing is possible) we also need to save:
- what preprocessed pattern analysis dataset was used (a priori the dataset would be saved somewhere so we only need a pointer to it, and the information about the options used e.g. stop words removed? stemming or not?)
- what workset of documents/chunks where used during in custom processing.
Log everything for evaluation purposes
- Saving sessions history automatically gives us some logs already.
- In addition we need timestamp each action (when requested and when the results come from the server to measure response times).
- We will need an IRB review to protect participants rights, privacy etc. Takes time... so we need to plan ahead to be ready when we have a functional system and real users.
Undo and redo
- if the state is saved automatically at every steps, undo and redo only requires 2 buttons in the UI (or can it be wired to the web browser next/previous buttons???)
Browse Session History (useful for users AND for us researcher as it can become a log data browser)
- At the minimum: the history can be displayed as a simple list of actions (e.g. 1) load MoA 2) search for "women" 3) order by lenght, 4) scroll to X, 4) select Y etc.), and users can return to any place in the history as long as the state has been saved at every step (possible here because the state data is small).
- Better: the history could also be shown in some compact graphical form, e.g. a timeline with different facets for different types of actions). I would guess that this visual representation will be a most useful to the monk-researchers studying the logs, not as much for the end user - because featurelens is relatively simple and its state is in most part independent of the order of the actions users took.
Share work with others
*At minimum: Add a menu item or button to "save a unique url for this state".
- this would generate a URL that includes all the state information as parameters. It could be sent to others or includes in papers to allow anyone to go into monk (as a guest visitor?) and featurelens to be launched and set to go back exactly where is was saved. Note: this is like what is done in google-map so you can send the map preset to show a specific address.
- Better: add other publishing mechanisms (see the collaboration cell work)
Annotate
- At the minimum: Attach text annotation to a given state of the interface
- better: also allow annotation of a text chunk, or a feature (i.e. a word or pattern), allow sound recording, g=hand annotation on an jpg image of the screen.
- the annotation could be saved in the user's space, or possibly published to be seen by others as well.
- The annotation action should be listed in the history list, and the list needs a filter to "show annotations only", but users will also need a way to see a list of annotation that spans multiple sessions, e.g. request a list of all annotations (and possibly show the location of all the text annotations in the overview, or in the list of feature, depending on what annotation we allow).
- Annotations have to be searchable! (to find them!)
- Annotations have to be exportable all at once to some normal text format, in one simple action! This is very important at the beginning when users do not trust the system to work reliably, or to last forever, which will be the case.
- Note: a priori, login not necessary until you annotate or run a custom analysis
|