Proposed user design specification: audience highlights

by maffew .a.t. purplebark .d.o.t. net
Composed November 2001
$Id: high.html,v 1.4 2002/12/30 12:33:28 maffew Exp $

Summary
Part of open publishing is open editing. Audience highlights is a way to make it easy for audience members to get involved in choosing the stories they think are best, in order to help other readers find them. This should help to clear the current closed bottleneck on editorial functions in indymedia.
See also:

Details

kellan was telling me about this idea where audience members can pick out stories that they think are good and add them to personal highlights pages.

i think this could be a breakthrough for indymedia, by allowing us to decentralise and diversify the editing process - how we choose to feature "good" stories.

done properly, it could have quite an impact on database design and performance. but i'll leave that for someone else to ponder.

good user deisgn is essential for the take-up of new software features. so i've been pondering how it might work. here's a stab at it:


Discovery by the user
---------------------

D1. on the front page we add a new small box:

	Latest Highlights

	Peace & Justice
	S28 8:52pm by AHippy

	Reports from the Forests of Earth
	S28 2:30pm by TreeHugger

	WTO Qatar
	S27 1:30am by WTOWatcher

	Passionate Rants
	S26 10pm by AllSeeingEye

	Outstanding Photos
	S26 9:23pm by rewire

	more highlights...

Note: don't show the same highlights page more than once in this list.
Some people may update their page with several stories in one session,
but they only get one slot on this list.

D2. at the bottom of each story, near the comments (& ratings) buttons, we
add a button that says:

	Add this story to your highlights page

It's important that this button is visible even when users are not logged in,
so that people who are not logged in (that's most of the audience) can discover
it. We can always get them to login after they press the button.

D3. I guess we also need a "member login" box on the front page once we
have logins.

D4. When displaying stories, also add to a right-hand sidebar a list of
highlights pages that have picked the current story. (Idea lifted from 
Three Proposals for Open Publishing which I think are excellent.)

D5. If the system is a success, there are various interesting ways the
info could be used, e.g. you could start to sort newswire stories by the
number of times they have been highlighted recently.

Adding new highlights
---------------------

After clicking the button from (D2) above, the following steps are
involved in adding a new indymedia story to someone's highlights:

A1. Is the user logged in? If not, present a standard member login (with
the option to create a login). Being indymedia, we need to be careful and
explicit about how we deal with privacy and anonymity.

Ideally, there would be options to log into a different indymedia server;
the URL for the story chosen would be passed along; allowing people to
pick out highlights from all indymedia sites as they read them and collect
them onto a highlights page on their home city.

A2. Once the user is logged in, the software checks if they have an
existing highlights page, and then generates a form:

	Adding [story heading] to your highlights page

	Please give your personal summary of the story or
	your reasons for highlighting it (optional):

		TEXTAREA [personal summary]

		[Strict limit on the length of this summary to 6 lines -
		checked after submission in case the user does not have
		javascript]

	The full rave (optional):

		TEXTAREA [personal rave]

		[A space for pages of comments if the user wants it --
		perhaps though it is better to instead encourage the user
		to comment at the bottom of the story - or the software
		could do both]

	Attach an image to this highlight (optional):

		By uploading a file

		OR

		Pasting an image URL

		OR

		Using original story's image (if one exists)

	If [the user has no highlights pages]

		Enter a name for your new highlights page
		(e.g. "Excellent Stories" or "Diversity Debates"):
			INPUT TEXT

	    Else [the user has one highlights page]

		The story will be added to your highlights page
		[user highlights page name]

		OR

		If you want to start a new highlights page,
		enter a new name here:
			INPUT TEXT

	    Else [the user has more than one highlights page]

                Choose which highlights page to add this story to:
                [list of user highlights page names]
			INPUT SELECT (I guess)

                OR

                If you want to start a new highlights page,
                enter a new name here:
                        INPUT TEXT

	EndIf

	BUTTON: Add story to highlights

A3. Process, and show the user a page saying it was a success when it's
done. Link to the newly updated highlights page:

	OK, we've added that to your [name of
	highlights page] highlights page.

Viewing highlights
------------------

V1. List the highlights the user has chosen for a given [highlights page
name]. Default to the most recently modified one for that user, unless
specified in the URL.

Make sure the page title uses the highlights page name and user name for
ease of bookmarking and google searching.

For each highlight:

	[story heading]
	[date] by [original author]

	[story image thumbnail if it exists]

	[personal summary] OR [original story summary if no personal
	summary given]

	Personal rave about this
	story...

	If [other users have also highlighted this story]

		Other people highlighting this story:

	        Peace & Justice
        	S28 8:52pm by AHippy

		... etc for each person who has highlighted this story ...

	EndIf

	... etc for each story ...

V2. Also give the list of other highlight pages by that user (if any).

V3. Make sure it's clear how to login, if the user is already logged in,
make that fact clear too.

V4. If the user is logged in, present various editing functions, such as
re-ordering, editing the personal summary / rave, grouping stories
together, deleting from highlights list.

V5. Button to compile all highlights on this page into plain text (like a
newsblast) and email it to someone. Email version should definitely *not*
include personal raves (only summaries), but might want to indicate if
more info is available on the website (e.g. with a [more...] tag like
active calendar emails do :).

V6. Button to make the page into an Acrobat PDF for printing? Not sure
this makes sense without some ability to edit the stories into condensed
forms or something. Something to think about.

V7. Button to subscribe to updates to this highlights page. Viewer chooses
whether to receive quick notes on email announcing new highlights, or
weekly summaries of highlights added.

V8. Just to keep your head spinning, I guess ultimately people may want to
add people's *highlights pages* to their own highlights page. Add a button
to do that at the bottom of every highlights page.

V9. People might also want to form groups that share a common highlights page
that they can all add to and edit. (Thanks evan for that idea.) You could do
that with a button at the bottom that says:

	You can allow someone else to help edit this highlights page:
	Their indymedia login name: INPUT TEXT
	BUTTON: Give edit access to this page

After confirming that the member exists, a screen comes up confirming that
access has been given to that user, and noting that the new editor will have
this highlights page show up in the list when they click on the Highlight This
Story button next time.

If there are already other people with highlight access to this page, you would
show a list of them in the sidebar and allow the owner of the page to remove
people too I guess.

V10. Allow a highlighter to subscribe to a random selection of new open
newswire stories to consider for highlighting.

I think this one could be important. Basically a potential problem is how new
story writers can gain the attention of existing editors and highlighters. By
default, anonymous story writers might have their stories lost in the noise.

One possible solution is to send all new stories out to several random
"editors", e.g. people compiling highlights pages. They might choose then to:
a) do nothing b) highlight the story on their own page c) say they don't know
enough to judge the story, and ask the system to forward it to someone else d)
nominate another highlights page who they think might be more appropriate for
judging the story.

Any highlighter subscribing to this would be able to set how many new stories
they want to see per day, or per week, etc. And also they could specify which
indymedia sites to get stories from (all, their local one, the "global"
www.indymedia.org site, a regional one, etc.).

Ideally there would be enough people volunteering to screen all new stories in
order to keep up with the flow.

This might be one important task which could be assigned to new local indymedia
volunteers, especially with a little training.

It might also be important and useful enough to make it the default for new
highlighters. It could be like their contribution in return for being able to
compile a highlights page on indymedia (although really the latter is hopefully
a very positive and creative solution too).


Heh. That ought to keep a coder busy. :) Wish I had time to do it myself. It's really exciting.

By the way, there may be useful ideas from rabble's "features" code that could be merged in. However, my impression (without any direct experience mind you) is that the features code is designed for people who know HTML. The above user design is aimed squarely at people who do *not* know HTML.

--
matthew arnison | maffew .a.t. purplebark .d.o.t. net

 ^   cat - community activist technology
  sydney, australia
 !   http://www.cat.org.au

plug into the radical info flow