UX doc for sitehome public aggregation

This is a UX doc for the proposal to make sitehome an aggregation of the public content of crabgrass sites

User Needs

  • ability to see cross site content in one place
  • to have a community / sitewide space to view content
  • the ability for non-logged in as well as logged in users to see this info.
  • a user should be able to feature their pages or their groups pages on sitehome

Site Goals and and their Ojectives

  • To enable users and groups to highlight their public facing content in a central location on the site
    Objectives
    • Have sitehome feeds pick up public pages only
    • Make clear to users that marking a page as public pushes it to the front page
  • To give the public an entry point into accessable content on the site.
    Objectives
    • Highlight public pages in the page feeds
    • Highlight public and open groups on the site home
    • Highlight active users with public profiles on the site home
    • Remove all crabgrass specific language from sitehome
    • The Custom nav bar links need to point to public content
    • The get started tips should have different profiles for logged in and non logged in users.
    • Search should return public pages only when not logged in.

List of Requirements/ Feature Description

  • Public pages. It needs to be clear for the users that when making a page public, it will be added to the site home page feeds. We could do this by using a tool tip when hovering over “Make Public”. If we do this then I would like to tweak the design a little so that “Make Public” has enough space around it, making it more “fitt’s” friendly. We might also want a bit of explanation text there, though we don’t have any other explanation text in the righthand page column right now. It also needs to be clear how users can get their pages featured on the site home page. Wires Needed
    • one possibility here
  • Public Page Feeds. The work here is to have the site home page feeds aggregate public pages. The feeds are: featured (these are set by sitehome admin, and we should only allow “featured pages” to be public), recent, most viewed, most active, most starred. We also need to get rid of “share with sitehome”, as all public pages will go to sitehome.
    • Featured Page Feed. Technically this is not a feed, as it is hand picked by an admin. At the moment, to add a page in the admin settings, you have to write the page title into the text field. I recommend having some kind of browse or search popup to find the pages that you want to feature, that only returns public pages. We also need some way of allowing users to recommend pages to be featured, though this could also be done via the starred feed (see wiki page about starred feed proposal). If no pages are ever featured, this feed does not show up. Wires Needed
    • recent: all pages sorted by last time they have been edited
      • proposal: at the moment this gives you the view of pages that have been created or recently edited, which could get very overwhelming on an active site. On a less active site, however, most recent edits is a useful view. We think a toggle between views: all new pages and all new edits, could be useful here (=> half a days dev work inc. tests/QA)
    • starred: pages starred in groups
      • proposal: toggle between views: popular and “up and coming” (whereby the site community can star interesting public pages, in a digg like manner. This is dev work that will happen in the future, not now, but I wanted to capture it now because it’s an important part of moving in the direction of making sitehome a community space, not just a broadcast space.)
    • most viewed: all pages sorted by number of views in given timespan
    • most active: all pages sorted by number of edits in given timespan
      => dev work involved in making feeds pull in public content only: two hours of work, inc. tests.

Research

sharing pages

How other sites manage sharing on their sites:

plone

plone sharing tab (who has permissions over the page):
skitch.com/pudsah/n6pds/plone-developer...

plone publish drop down (who can see the page):
skitch.com/pudsah/n6pd5/plone-developer...

vimeo

vimeo privacy symbol:
skitch.com/pudsah/n6pd6/crabgrass-user-...

vimeo privacy settings (who can see the page):
skitch.com/pudsah/n6pg4/settings-for-cr...

wordpress

wordpress publish portlet:
skitch.com/pudsah/n6pre/edit-page-pudsa...

wordpress status expanded (drop down options are: Published, Pending Review, Draft):
skitch.com/pudsah/n6pfb/edit-page-pudsa...

wordpress visibility expanded:
skitch.com/pudsah/n6pft/edit-page-pudsa...

facebook

facebook sharing posts on the wall:
skitch.com/pudsah/n6pgr/facebook-sisi-nutt

Information Architecture

Wires

User Scenarios

User Flows

Design Proposals

 

oo, lots of stuff here. nice work, bullet point comments below. i’m also currious about the plan to move from this into a phased approach and determining what happens now and later.

  • “Site admins should be able to set a site to be completely public by default.”
    • this is a different but related problem – i would propose keeping this seperate as it brings with it a whole bunch of issues. we can still have sitehome as public face and aggregator without this.
  • there is a mod already that make it so users are directed immediately to the sitehome.
  • right now an open group only means its open to join, not that all content is public.
  • “The custom nav bar links need to link to public pages” —> interesting. i think siteadmins should have a choice, but it does make sense that non-logged in users would only see links they have access too. hmmm.
  • “should only allow “featured pages” to be public” —> do you mean featured pages should only be allowed to be public?
 
   

this needs to be updated – the current thinking is that we need to have two options on the page, and there are different UIs that can tackle this, but we need to be able to “publish” to sitehome vs making a page public. it is messy and noisy to pull public pages on site home, users should have the option.