[OH-Dev] pycon sprint: working on OH site UI/UX relating to project addition/management

[Flora Worley]

Hello OpenHatchery!

My name is Flora and I am a new contributor to OpenHatch--so first,
"hello!"--and I am very excited to be working with Asheesh and many other
contributors on the OpenHatch project during sprints week here at PyCon. I
am a huge fan of the project, and am really hoping to be able to contribute
to making the site even more awesome.

I am here at PyCon as a relative newbie to the language (less than one
year), and have been developing my skills in Python largely through my
participation in Pyladies as a co-organizer of the Portland chapter.
Because I am coming to Pycon with still-in-beta Python abilities, I elected
to work on some UI concerns that Asheesh outlined relating to the
bug-tracker ("customs", "+projedit") pages--I should mention that my
training and experience is in front-end development and UX.

In auditing the user-flow and interfaces relating to adding bug-trackers, I
came up with some ideas that I've discussed with Asheesh and would like to
share with you all for feedback. I will try to outline, to the best of my
ability, what we discussed below:

Design rationale:

You really have two sets of users visiting the site:
     1. (Mostly) beginner developers, like me, who are coming to the site
to search for projects to contribute to and to share contributions with
others
     2. (Mostly) more established developers who would like to list their
project on the site for the purpose of having newbies like me help with
smaller bugs
     == these can be one and the same person (and the OH site doesn't
distinguish b/t them now) but my sense is that they often aren't. This
bears on the use-cases and user-flow relating to adding bug-trackers to a
project, in particular.


Issues we're trying to address:

1. Currently, the user-flow for adding bug-trackers is unnecessarily
circuitous, and there are two different paths that lead to two different
interfaces:
a) Projects page "Add bug-tracker" link--->bug trackers wiki page--->user
profile page (instruction #1)--->"Add project" 'nudge' button--->(add a
project form/submit)--->click project name, scroll to "Add bug tracker"
link---> .../+projedit/projectname----> click on your tracker link and fill
out/submit form
b) Projects page--->"Add bug tracker" link--->bug trackers wiki
page--->.../customs (instruction #2)---->"Add tracker"---->fill out/submit
form

2. As you can see above, there are two different 'add a bug tracker'
landing pages you might arrive on depending on which route you would take.
These different pages fulfill different functions: "/customs" additionally
lists other projects using the same bug tracker and allows you to
edit/delete your project from the list; "+projedit" enables you to
configure setting related to the project you want to track

3. The "Add project" 'nudge' button leads to a page that addresses the
contributor only, making it confusing for the developer who simply wants to
register her project for the purposes of getting help with bug tickets.

4. Many of the fields in the bug-tracker forms (ie, that collect data that
OH uses to configure and pull in bugs) are not only not necessary, but are
explicitly deleted upon collection in the models.


Possible solutions:

1. Address the user-flow issues by providing paths for each use case on the
user's profile page--ie, 'nudge' buttons would address those 1) looking to
contribute (ie, present "volunteer" button); 2) wanting to list their
contributions for social purposes (ie, the function of the present "add
project" button); 3) wanting to add their project to the bug-tracking
database (new option)....[see attached screenshot]

2. Merge '.../customs' and '.../+projedit' into a unified, single-page
interface for managing project settings, including adding/configuring the
project's bug-tracker. When user adds a project through this interface, it
will be added to that user's profile page in the same way as "Add project"
is.

3. When a user adds a new project through the new settings/tracker
interface, that user's project listing on his/her profile would then be
tagged as such, enabling that user future access to return to the
settings/tracker page for the purposes of editing settings or deleting the
project from the database.


Possible "next steps":

Ridding the home, "dashboard" page of user-specific widgets--getting rid of
the redundant "Projects" box altogether, and moving the "training missions"
widget into the user's profile page.

Make the "recent activity", "news/blog", and 'join our community/mission
statement' front-and-center forms of address.



....I'm wondering what everyone thinks, and if there are any
issues/concerns with this approach and/or whether anyone has any
alternative ideas, thoughts, etc.?

Again, really excited to be in everyone's company here--such a fantastic
project!

Best,

Flora
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhatch.org/pipermail/devel/attachments/20130319/8427f283/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: profile_nudges.png
Type: image/png
Size: 193195 bytes
Desc: not available
URL: <http://lists.openhatch.org/pipermail/devel/attachments/20130319/8427f283/attachment-0001.png>