Layout Design - Graph Editor

[aperritano]

Per our skype conversation, here are some of the interface ideas I was mentioning that possibly could be used to provide a consistent look and feel and improve interaction. This is a riff and not necessarily tied to color, naming, component placement, icons, etc... more about layout and making tools more accessible with a responsive material design that adjusts to any screen size. This is the basic material layout for a laptop screen size. For example, when viewed on a mobile device 1. would collapse and a slide out when the hamburger button on the toolbar is tapped.

The main area (red rectangle) can be swapped out depending on the context (e.g. graph editor, session configuration, teacher/student previews, etc..)

1. Basic navigation and functions for the context that main area is in.
2. Operator action before the session starts.
3. Operator lane, doesn't tie the operators to a specific lane.
   3a. Icons on the activity bar make it easier to id activity types. +lane labels
4. Top bar, all the functions here should be based on what is in focus in the main area. Drop down menus for session choices and graph choices.
5. open activity descriptor, when the activity bar is selected on the timeline, it appears here with a screen shot of the tool, a short description, icon, and fields to configure.
6. Always on top floating action button for creating social and product operators.

original

Resources
Material Components
Material Layout Tester Tool
Color Palettes and themes can be generated with google's tool

[lfaucon]

That looks great!

I believe Stian and I lack the basic knowledge about layout design. Even though we went together to a talk about user testing 6 months ago, we haven't done anything about it. I really appreciate your input on this.

It would really help us if you set up the first steps. I think the first two points to work on would be 1 and then 4. For point 1 the only code that needs to be change I think is in imports/ui/App. The way it is implemented now is a big switch/case. Point 4 is slightly more difficult as it will be different whether the open tab is GraphEditor, TeacherView or StudentView (Don't bother with Admin and Home). Everything should be in imports/ui/GraphEditor, imports/ui/TeacherView or imports/ui/StudentView.

For the other points concerning the design and layout of the graph editor, I like your suggesting but I'd rather wait to have Stian opinion about it too.

Thanks

[houshuang]

I second @lfaucon that the immediate impression is a much more professional and consistent interface, and I'd love for us to work towards something like this. We have really lacked someone with design sensibility, and we will very much appreciate your suggestions, but also your ideas about what is the best process for doing/discussing the design etc.

Although our design is very basic, we have been experimenting with a lot of different approaches in terms of usability, so let me provide some comments.

• How to manage the sidebar (5)
  • I experimented with having it slide out automatically whenever an activity was selected, however we perceived that as quite disruptive. You have the choice between either compressing the graph, or keeping the zoom level, but hiding half of it. There's also a discussion about which actions in the graph editor should lead to "selection" - if you click and activity and drag it to move it, does it get "selected"? We could of course have a special editing mode, which would only be triggered by say Ctrl+Click, that would make the automatic expansion less disruptive. But it's not unproblematic.
  • We also experimented with always having it there, but it's a lot of screen real-estate, especially on a laptop-screen.
  • Currently we explicitly expand/close it, either with a keyboard shortcut (w) or the expand/close buttons.
• The operators
  • Recent feedback from several people (including you) has strongly suggested that our current way of approaching this is unintuitive, people think that x,y coordinates have semantic meaning etc. However there are other issues too.
  • Currently in our architecture we have two types, which are programmatically different. We intend to add at least one (control operator) and possibly two (sink operator - nothing going out in terms of the graph, this could be posting to an external API etc). Basically all operators receive the same input, but can produce different things as output. For the S and P operators, we have different symbols. These were chosen quite quickly and without a lot of thought - the social one is OK, but the product one could use work... Or maybe it's OK, once it's learned...
  • But a big point is how much information a graph can convey just by looking at it - right now, the activities convey plane, time/sequence, and a name... The operators should show inputs and outputs (clearer than today), but don't tell you anything about what they do. We've toyed with the idea of having more categories of operators (aggregation, disaggregation, transformation etc) with different icons - but this would be hard, as some operators could be difficult to categorize... There could also be something in the way the arrows are drawn to distinguish aggregation from disaggregation? Do we need to display the name of the operator directly on the graph, or with mouse-over?
  • I'm concerned that the example you chose is a very simplistic graph - what we've found is that as graphs become more complex, it is very difficult to show the information required in a clear way. This both applies to a bunch of operators that are interconnected (seeing connection between them), and with multiple stacked activities. What would be great is if you could try to represent a more complex graph, like the one in the Hypothesis video, in this interface. Can one still clearly tell which operator is connected to which other operator, and which activity?
  • (one idea here was to use color, for example if I selected an activity or operator, I would highlight all first-order incoming nodes in one color, all of their incoming nodes in a weaker version of the same color, and the same principle for outgoing nodes... That way you would at a glance see which things are interconnected/interdependent)
  • Also note that currently operators can only run a single time, in the transition between two activities (or at the beginning), however we are planning to fairly soon (within the next few months) add live operators, which can connect two activities that overlap (or even be fetching data from an external API every n seconds/minutes, etc). Does that change anything?
• activities
  • I see you have small icons on the activity boxes. Are these per activity or per category? We have had this idea for a while, one point would be to distinguish between a placeholder (where you double-click to add an activity, and have not yet chosen the type), and a configured activity. I thought about each activity bundling an icon (as an SVG), but it's also a lot of work to find a unique one every time you come up with a new activity... Then I thought about categories... right now the graphical system doesn't actually tell you anything about what people are doing in an activity, other than whether it's individual/group etc. For example Laurillard's system has color coding for categories in her system, a bit similar to Bloom's taxonomy, and she shows pie charts of how much of student time is spent in "receiving information", "debating", "creative work" etc... However, those categories aren't really part of our theory...
• Left sidebar
  • I am worried about this being always expanded, again I think real-estate for editing the graph will be key... The way we are doing it is to have an time axis that always moves right, because of our theory. Other approaches, like LAMS, let's you do kind of a spiral, to optimize screen real-estate... But because of that, it will be important to see as much of the graph as possible.
• Teacher image
  • looks good, but most teachers will not upload images of themselves :)
• User interaction
  • not necessarily part of this design, but informs it - do you see other/better ways of interacting (creating new activites etc) than currently? What we are planning to add is some more batch editing (select multiple activities either by control-clicking, or by dragging a box, cutting/pasting etc). Other stuff?
• Feedback consideration
  • not sure how important this will be for this design, but a significant effort will be in making it easier for designers to design correct/runnable graphs, and prevent/notify about incorrect graphs. This includes only being able to drag between things that are compatible, showing inconsistencies (maybe with red outlines, but perhaps also with a number which when clicked gives a list of issues, etc).
• In general
  • I think this is going in the right direction although there are a lot of things to think about. One important part will be to rethink the entire teacher interface as a single "tool". So far we have the different views as completely different elements, with no consistency or interaction between them. What we should do now is to start thinking more about the workflow of a designer/ teacher - they design graphs, they browse existing graphs, they want to run a session, looking both at the graph in progress, various dashboards, perhaps flipping back to edit mode to modify the part of the graph that has not run yet, etc etc. And more clearly separating the teacher view, from the student view, which is really only given by the running activities (although even there we can in the future provide more flexibility than simply splitting the window in two, for two activities).

[pmitros]

Big move in a good direction. The dummy data is a bit of a problem. It's not clear how this would work in the context of a real classroom exercise.

One of my big problems with this user interface is that there's not enough information there to understand what's going on at a glance. I often see graphs with many lines, but I don't know what those lines mean. "Hello Activity" and "Brainstorm 1" aren't enough to know what those are. There's a lot of semantic meaning that's absent, which is how I like to think about the lesson.

As a teacher, I'd like to know:

"I am working on a lesson on ethics. I have students individually read about different theories of ethics. I'll have students watch a video about a difficult ethical situation together. Then, I'll have them analyze with their own theories. Finally, I'll have them discuss."

That's a little bit more than:

"I am on lesson 5. Students do a read activity. Students do a group video activity. Students to an individual analysis activity. Students do a group discussion activity."

Something like a one-liner "Hello Activity" doesn't give enough context. You need a little bit more there.

In many cases, the data flows are also not clear. There are lines, but it's not clear which way the data is flowing or why. A simply improvement would be to have a lesson description, as well as make the activity pieces multi-ilne with more context.

Is there a list of use cases somewhere to start from?

[houshuang]

We don't really have a formal list of use cases - we have some scripts in "mind" which we have tried to design (focusing more on data structures and engine flexibility, not so much on design). I have lot's of links to lists of pedagogical scripts from similar platforms, which I have been meaning to analyze to extract common sub-patterns etc, but I have not gotten that far yet.

Mock-ups and ideas are welcome. One thing is the operators (location, design, showing title on the graph?, links and directionality etc). Another thing is the activities - we could add color (indicating what?), icons (per activity type, or per "category of activity type"?), multi-line text (but that would require more space etc), mouse-over text/description, etc.