• User Experience Improvement Strategy

last modified March 18, 2009 by Lily

This document represents an attempt to develop a strategy for improving the user experience in OpenCore.


--------------------------
Assumptions & Broad Goals.
--------------------------

There are larger questions that still need to be addressed; we can raise them here, but will focus here on creating sets of actionable items.

There is plenty of low-hanging fruit to pick, that doesn't require resolution on larger questions; let's start with those.

We haven't been able to produce A-grade user experience in opencore. We need to step up and really nail the usability, interaction design, and execution.

As much as possible, we'll attempt to use metrics to support decisions, to guide strategy and then measure the success of our ideas.

To start, we will implement changes in the context of the Livable Streets Network, since there is a narrower audience there, and success there benefits our Livable Streets initiative. However, we plan to integrate changes back into the core of OpenCore, and consider this an OpenCore UI initiative.


-----------------------------------------------------------------------------------
Bigger Issues. We might not be able to solve these right away, but we'll keep thinking about them.
-----------------------------------------------------------------------------------

B01: Many people are setting up, then abandoning groups. Lots of groups were created, then never used -- one member, no pages edited. Interpretation: people want to start something, but aren't sure how to use the tools.
Note: either people aren't sure what to do, or we aren't offering them something appropriate
NEED: more metrics on how projects are being used. "drop out rate" or similar.

Email Notifications is one way to get members active. Simplifying the Invite process will also facilitate use. Also, a lot of applications go through this "shout out phase" where people hear about the application through conferences. They join right away with excitement and then don't come back to use it; this is not an uncommon occurrence.


B02: It's not clear what it means to be a member of the site or of a group. Related to the point above, we're not giving people a clear enough purpose for their presence on the site. People have created accounts, but aren't sure what to do next.

time-committment.1.pngB03: How do we support various levels of committment? Creating & using a group is high, long-term committment. Commenting on a blog post is short-term, lowish committment. See diagram at right.

B04: Browsing projects and people is not really possible. I want to find people and projects that might interest me, or at least browse through them voyeuristically. I'd like to search by location, interest, and recent activity. (being able to see the # of people in a group would help draw me in.). Search + Browse aka Find problem.

B05: There's little integration between applications. Information tends to get siloed according to application, which is often counter to the user expectation. For example, a "recent activity" feed on the user profile, across all apps, would be useful, but hasn't been attempted yet. See also Search.

B06: You can't search very well. It's not possible to search everything and get all your results in one place.

B07: Activity gets hidden inside the site. It's hard to tell where things are happening on the site. We should find ways to expose activity on the site, perhaps through a cross-project activity feed, or by featuring projects and/or people who are doing lots of things on the site.


------------------------------------------------------------------------------------------
Smaller Issues. These, we can pick off one-by-one and make improvements, independent of larger issues.
------------------------------------------------------------------------------------------

S01: You can't contact other members. This is a simple, core activity -- we're trying to connect people, but we don't give them a way how. In other words, it's not very functional as a social network in its most basic way.

Options here include an internal messaging system (keeps email completely private) or a member contact form, which sends an email.
The Team page in this link address the above concern. It also covers Search, Pagination, Inviting new members and consistency between Admin and Member screens.

S02: People should be able to "just join" projects. Without moderation -- i.e., this project is open to any LSN member. Creating an account shouldn't be a barrier to this process (do it inline with the join process).

S03: The invite members interface is bad. Doesn't need to be divided between username and email. results are hard to find when you get them.

S04: It's about local places, but it's not very geo-based. Location should be part of more activities on the site, particularly people, projects, and potentially other ideas or units of info.

S05: List emails should be available in batches. Not everyone wants each email as it's sent. This is a pretty standard feature.

S06: It's easy to clobber each other's wiki edits. There's no way to know when someone else is about to edit a wiki page you're working on.

S07: You can't delete your account. You're ours, forever!

S08: UX issues throughout Listen. It's generally bad looking, in terms of web design. The project owner's perspective is particularly bad (home screen being list of lists, when most projects only have one list). You can't delete posts from a discussion archive.

S09: Managing files/attachments is difficult. For example, there's no way to link to a PDF from a blog post, and attachments can only be added to wiki pages. Linking to attachments from wiki pages is not intuitive. Collaboration around files (discussion, etc.) is not currently supported.

S10: Xinha has many usability problems. These are pretty well known, and are already beginning to be addressed. Specific issues include: difficulty in inserting and managing links, unexpected behavior when formatting text (particularly around bullets and line breaks), and workflow for uploading and managing images.

S11: Permissions aren't always granular enough. For instance, a "public" group often has certain pages it would like to remain private to group members. Or a public group might have a mailing list that they want to keep private (still archived, but invisible to non-members).

S12: Furthermore, permissions are overlapping and confusing. While not granular enough in some places, permissions are confusingly distributed in other places. For example, mailing lists have managers that are separate from project managers. (suggestion: permissions & capabilities throughout the site should be mapped out and analyzed, to find areas of confusion).

S13: Site administrators need more control. Currently, site administrators (aka community managers) don't have the ability to track and/or moderate content effectively on the site. A "control panel" showing activity on the site (new members, new projects, new discussions, etc.) including basic moderation tools (deleting spam members) would be incredibly useful.

S14: The "pages" and "contents" buttons are confusing, and somewhat redundant. The "contents" view is not particularly useful, except as a list of wiki pages, in which case it should just be that, and should be more closely tied to the wiki pages section. Additionally, there have been some requests from our users to change "pages" back to "wiki" -- this terminology is still a bit confusing.

S15: Becoming a site or project member is often too much of a barrier to participate. For example, in this project (http://www.livablestreets.com/projects/nyc-bridge-wiki/lists/nyc-bridge-wiki-discussion/archive/2008/09/1220279389885/forum_view) the project owner is hoping to solicit feedback. Surely he doesn't realize that people will have to first join the project or subscribe to the mailing list to post a reply.

S16: Notifications aren't always in the right place. For example, notifications about project membership (to projects you're an admin of) show up on your account page. This information would be more appropriate on the project page (could show up in a project activity feed if you're an admin). An analysis of what notifications are sent where & how might be useful here.

S17: Project administrators can't see project members' profiles. Moreover, the project admin screen is dry. In the spirit of One Interface, it probably just makes sense to work the admin functions into the public view of the team.

S18: The groups homepage is too static. The "start" and "find" boxes take up prime real estate at the top of the page that could be better used to highlight actual activity on the site.

S19: If you delete your default mailing list, you can't create a new one that auto-adds group members. "Auto-tracking" lists were created as a special case for the first list created for a given project, and were never added as a list-type you can choose from when creating new lists. This is a pretty low priority, as most projects don't have multiple lists.