Thinking out loud: levels of detail and editing
Tuesday came and went but the cold stuck around. Following are notes on current explorations, relating to this, assembled through a fog of sinus and intense facial suction.
Levels of detail
We call them LODs, and so far they go from 0 (zero) to 3 with varying amounts of zoom within each. They serve different purposes, such as allowing a user to either get very close (or even into an activity to edit all of its components), or to pull far back and evaluate the progress of a project. Up close you see editable text fields and calendars and tags and status colors — this is LOD 0, originally named hyperzoom. The idea was that instead of having pop ups to edit attributes of an activity (such as who’s working on it, when it’s due, what materials are needed to complete it, references ..), why not actually go into the activity and have that be a vast space where all of its parts and assets are visible and directly editable. Just by selecting and typing. This helped remove unnecessary clicks and scrollbars and saves and confirm dialogs (very web), and coupled with a smooth zoom in and out introduced a more frictionless experience (very game).
That’s cool, and it’s kind of where we’re at right now. One side effect is that you end up zooming in and out quite a bit, and although that’s a lot of fun, maybe there are ways to alleviate some of the back and forth.
One solution is incorporating the modeling wheel within LOD 0; at the moment it’s limited to LODs 1 and 2, as those are the views where it’s made the most sense to have it. Zooming too far away from activities makes creating them impractical, you wouldn’t see them. Besides, the idea is that from far away you’re viewing progress — status colors fill the shapes of activities and groups and you’re hopefully you’re seeing a lot of green and yellow (completed and active tasks). Blue means upcoming or planned, and pinks are milestones. You also see red beacons from way far up, those are alerts.
Where was I.
Yes, the modeling wheel, and zooming in and out to edit activities.
Activities can have resources attached to them (people, locations, files…), and adding these are a function of the modeling wheel, as are grouping and deleting. It pops up when invoked and you drag objects out of it. It takes a couple of tries to get the hang of it, like any game command, but once you get it the experience is quick and intuitive. It’s a one-swipe operation — click-hold and drag through an icon and release to drop something onto the game board — and you can do this quickly.
The downside is that this quick-swipe operation needs to happen every time you add, connect, or remove something. To solve this, an option we’re exploring is letting the wheel stay visible once activated, allowing a user to add many elements while it’s active, which would make it behave more like a tool palette (and introduces more clicking). On the upside, this means we can add sub menus, which saves the extra step of zooming into LOD 0 after a resource has been added. Submenus would allow a user to select a person resource, for instance, and suggest users based on what the app has learned from the type of activity you’re creating. Or you could have favorites. The extra clicks would make up for needing to then zoom into LOD 0 to assign a user. Plus you’d get to add a bunch, populating the activity with several resources in one go. The modeling wheel is going through redesigns this week, addressing both functionality and appearance, with animation and dev testing to follow next week.
That being said, another approach has been floating around my head. Since the goal is to facilitate the building and editing of a project map (in a way that is quick and intuitive), why not tie functionalities more directly to LODs. This would remove the extra layer of of commands (invoking the modeling wheel) and automatically adapt usefulness to view levels. Over time and with user feedback, we could adjust the options to better fit their needs, but could also build mechanisms that intelligently guess what a user might want to do next. This still involves sub menus, but in this case the interaction is contextual to whichever LOD and/or object is in focus.
In this scenario the modeling wheel would be more of a HUD-like, floating tool palette which could be freely positioned. Tools would adapt to a particular view, contextual to whatever is selected. This also offloads some of the tasks and adds editing options directly onto objects, which vary depending on which LOD a user is in. An example would be that in LOD 1 you wouldn’t want to connect activities since you’re too close and focused on editing, but in LOD 2 you’d be able to connect just by dragging from the tip of an activity to another one without the wheel. If the wheel is now floating, simply selecting an activity would allow you to add resources to it, and coupled with sub menus you’d be able to quickly populate it with pre-filled elements. This removes LOD 0 entirely and spreads edit functionality over several views in a way that is logical to whichever level of detail is active.
Following are mockup sketches with notes.
Above is an example of LOD 2 in this direction — status (blue, as in planned), title, start or end dates (or duration), and number of messages are visible on an activity. On-screen the activity would be smaller until a user moves into LOD 1. In this setup, the pointed tip would react to a click and drag and allow a user to connect activities without the need of invoking the modeling wheel.
Following this, LOD 1 would add an edit button to the activity. More information would be visible, such as which participants have added messages to this activity, sorted by most recent. The message bubble would pulse for unread messages and turn red for alerts. The status color has been minimized to a colored line that runs the bottom length and the tip of the of the activity is inactive, since connecting at this level of zoom would be less efficient than at LOD 2. One option might be to add linking to the modeling wheel at this LOD, where it auto-fills with submenu choices of neighboring activities. Below is an example that adds more info like who created the activity and when, as well as who last edited it (added a resource, for instance) — this could be visible pre-edit state. Clicking on whoever created the activity would open up a messaging panel.
Above is the same activity in LOD 1 after having clicked the edit button. Text and elements are slightly reduced and slide to the right, allowing for an edit panel of options. This frame is an early exploration and leaves out a messages feed that would fit where message and activity stats are currently shown — as suggested earlier, what’s currently visible in the right would probably be in the pre-edit state.
From here, a user could change the status from planned to active or done, change this activity to a milestone, and do a number of edits usually reserved to the modeling wheel — such as adding resources by toggling the + icon to reveal resource options.
Instead of needing to fit all edits within the activity space (like we currently do in LOD 0), certain tweaks would exist within panels, the results of which would be displayed once closed, like duration or due date. Adding or deleting tags would simply be a matter of typing or clicking the x next to existing ones assigned. One option would be to add a tag button which would open the tags panel (currently a menu item at the bottom of the gameboard, not seen here) and contain project-wide tag editing features (color, removing tags, or filter activities by tag). For now, and for the sake of speed, all one would need to do it click and enter a tag name; existing ones would auto fill as a user types. Currently, we include all tag editing functionally within LOD 0 and because of this (and the lack of space), projects with large amounts of tags result in awkward layouts and too many options for what should be a quick and simple action.
One solution to relegating certain edit tasks to the activity itself would be the inclusion of secondary menus within the left-side options panel. A digital resource, for instance, could include a sub menu of options, such as an image, link, or voice note, which would automatically be attached to the activity when created and display the icon matching the file type in the resource image (currently, all digital resources share the same file icon). In the example above, both the digital resource and calendar are shown as active with their respective sub option(s); in the case of the calendar, it could be duration.
This could theoretically remove the need for LOD 0 altogether, or that view might become a reading view, with all the elements laid out and freely movable (if, for instance, an activity has a lot of image references). It could also give breathing room to messages (instead of the limited scroll in LOD 1) and allow for the addition of stats within an activity. The view itself could be reorganized to make everything relating to an activity more legible — notes and descriptions could be assembled in a way that makes reading through an activity, its description, resources (and their descriptions) more natural. It could also open up the possibility of allowing messages at the resource level, since there would be plenty of room, which is useful in projects that rely more on assets and iterations over time.