MacGuffin Design Jam
Saturday’s design jam at MMU (led by fffunction’s Dan Goodwin) generated loads of functionality ideas. Over four intensive hours, the participants set to working out what MacGuffin should do for writers, readers and literature professionals (and also, crucially, what it shouldn’t do – more on that later). Here they are, jamming away.
From L-R: Brett Janes (writer and spoken-word compere); Chris Wilson (MMU App designer); Darren Dancey (MMU Lead Researcher); Aisha Shariff (Y/A reader, writer and Wattpad user), Gillian Knox (volunteer facilitator); Craig Pay (writer and writing group leader); Adrian Slatcher (fiction writer and digital development consultant); Paul McVeigh (writer, blogger and festival manager); Rachel Winterbottom (MUP Publisher and Y/A fic reader); Dan Goodwin (fffunction); Anne Caldwell (Creative Writing lecturer and NAWE member); Ian Carrington (Bookseller, spoken-word compere and writer).
The session comprised of four chunks:
1) Design the box
2) Consuming content
3) Uploading content
Design the Box
Dan divided everyone into two smaller groups, each furnished with a blank cereal box, post-it notes, pens, and the brief to imagine that MacGuffin was being sold on a supermarket shelf. What do we put on the box? Who are we targeting it to? What are the USPs? What’s tasty, and what’s nutritional information?
Interestingly, both groups immediately seized upon the idea of MacGuffin as a writer-development tool (though you might attribute that in part to the number of writers present).
Some thought MacGuffin ought to supplement (or feed into) traditional publishing models, with a selling point for writers being that popularity on MacGuffin would lead to publishing industry exposure (which, it was suggested, we should perhaps formalise, with organised industry exposure for the most popular work?).
Others saw MacGuffin as a laboratory to garner feedback from a sympathetic writing community (because you can target your work-in-progress directly to very specific interest groups). This is, I guess, the ‘nutritional information.’ It also led to some useful functionality discussions about whether you should be able to publish work-in-progress to a ‘closed group’ before ‘publication proper’. Both groups also recognised that MacGuffin has to target writers themselves on launch (including influencers), to build a critical mass of content.
The unifying USP – the tasty bit – (for both writers and readers) was discovery. For writers, it’s about finding the ideal readers for your work. For readers, it’s about finding the ideal story (or poem, or novel). This led to proposed strap-lines of ‘Discover, be Discovered’ & ‘Bringing Readers and Writers Together.’
We split into two groups to imagine how readers will find, consume, share and tag content on MacGuffin. This left us with a shopping list of functionality requests, and some fairly important questions that still need to be decided. Here’s a large sheet of paper with them scrawled on it:
Find, read/listen, and tag a story.
- Can search for stories of certain duration (e.g. story for my commute).
- Can see which tags have been added by the writer, and which by other readers (e.g. some sort of colour code). This would help give a more balanced opinion of quality and content.
- Can follow specific writers and getting a notification when they upload new work.
- Suggestions of new content based on what you’ve previously read.
- Suggestions of stories beyond the ‘most popular’ in each category (otherwise popularity becomes self-fulfilling), e.g. an ‘I’m feeling lucky’ button?
- Can click into MacGuffin (linking SM/forum users to content on MacGuffin), direct to specific content, and share it outbound.
- Separate indication of the quality of the audio, warning the consumer of poor quality audio beforehand. A visual cue for this, straight away – ‘Sound Quality’ – which people can vote up or down.
- Can read/listen to previously saved content offline (e.g. before you travel out of 4G network reach).
- Can bookmark/resume story.
- Can tag while consuming (whether audio is playing or reading text) rather than waiting until the end. On YouTube, you click like or comment while watching. Jury out on whether this ought to be time-specific like Soundcloud or Genius (i.e. tagging a specific point). In this case comments should be hide-able, as they could be too distracting for some readers.
- Ratings, tags and navigation fully accessible to visually disabled users.
- Can opt in or out of any geolocating data gathering (most people not keen on gathering data that might be able to identity a user, where they’ve been, or what they’ve been reading).
- Taggers prompted with popular/suggested tags (this may be an autocomplete function – as tagger begins to type, previous or popular tags are suggested).
- Will users rate each story (e.g. 1-5, sliding scale)? Or give it thumbs up for good content? Thumbs down for bad? Does this even need a negative indicator, or will a lack of positive votes do that?
- Should hashtags themselves be up-voted (e.g. ‘was this tag helpful?’), as a self-policing mechanism (which might solve some moderation issues)?
- Should audio uploads should be moderated for audio quality? Or let tagging/up-voting do all the work?
- How visible are readers going to be to each other? E.g. seeing other friends’ and their activity on MacGuffin? Can users see what friends have been reading (or do we route this away from the app itself with posts/shares to established SM – otherwise we’re in danger of inventing a SM platform).
- Privacy: does anonymization of users help allay concerns? What’s the actual value of geo-location data to writers, readers and lit professionals?
- How do we make the MacGuffin UX design appropriate to first-time users and returning users? Will quality/attractive content be immediately visible to both of these groups (get this wrong and we’ll lose users!). Chicken and egg scenario.
Again, we split into two groups to tackle this question, then reported back on our findings.
uploading a story (text and audio).
- Formatting should be standardised, to prevent ‘wacky’ and annoying formatting (though this may be detrimental to poetry).
- Can paste-in text.
- Compatibility for C+P from MS Word, Scrivener, and iPhone notes.
- Basic formatting functions: Header (1, 2, 3), justify & align, italic, bold, line-break, tab/indent.
- Instructions and demos of audio recording, editing and upload.
- Can upload direct from mobile device.
- Facility to pair-up writers with volunteer readers (voice actors). Community?
- Tagging writer prompted with popular/suggested tags (this may be an autocomplete function – as tagger begins to type, previous or popular tags are suggested).
- Differentiation between writers tags and readers’ tags.
- Auto tag-generation (story length in words and audio length?).
- Closed group for sharing work-in-progress.
- Prevent copy and paste of text.
- Should a writer be able to upload a story with no tags at all, and let the system of end-user tagging take it to its natural audience?
- Should a writer (a poet, specifically), be able to upload an image/pdf of their poem?
- Will writers have revision control? Can they go back and edit a story after other people have tagged it? What are the implications of this? Does it matter?
- Comment/tag moderation. Who moderates trolling/vandalism? The community?
- What’s the mechanism for reporting content?
- If users are sanctioned by the community, what’s the mechanism for that?
- Audio recording will definitely put off some authors (both in tech terms, and simply because they’re not good readers).
- MacGuffin needs to piggyback on learned behaviours and skills the authors already have. But it may be that if some early-adopting writers blaze a trail on MacGuffin with impressive results, others will make the effort to follow.
- Writers might conceivably extract audio from previously recorded video performances of their work. How do we help/advise?
- Upload of audio that’s been recorded on a mobile devices gets much more difficult when the story is long, as this limits how you can transfer the audio file to another device.
Two sub-groups tackled the thorny issue of analytics: writers and literature professionals. Overall (though not unanimously), both groups felt that the analytics raised serious privacy concerns, especially when it comes to geolocation, and that these are in danger of outweighing the benefits. Members of both groups questioned the value of the analytics at all (‘why would anyone want this information?’), although some writers and publishers thought they would use analytics to learn about their readership.
Functionality requests (writers and lit professional combined):
- Can see referral data – how readers arrived at the story, from within MacGuffin and from without (SM, forums, Google, etc., and filtering out robot hits vs real readers).
- Can see how many people read a story.
- Can see how many people shared a story, and follow the ‘journey’ of a story as it was shared from user to user.
- Can see how readers use tags to find content (e.g. a reader might begin searching for ‘#crime’, then add the secondary tag ‘#Manchester’ to their search terms).
- Can follow the rise (and fall) in popularity of individual tags. i.e. what’s trending.
- Can see information on the ‘act of reading’ – where and when people are reading. Geo-location balanced against privacy concerns – e.g. not on a street-level of granulation, but by broader area.
- Can see when readers leave a story (as a self-editing tool for writers). Differentiate between audio and text versions, and between readers pausing a story and leaving it.
- Can follow the rise (and fall) in popularity of individual authors.
- Can use demographic information to filter analytics results, such as age, gender (this might have to be opt-in).
- Can compare the attributes of the most popular stories on MacGuffin (length, genre, subject-matter, meme, tags).
- How do we protect people’s privacy, while at the same time gathering useful data for writers?
- How do we make visual data (e.g. maps showing locations of story reads) accessible to disabled users?
- We need to persuade writers, first and foremost, of the benefits of analytics.
- Geo-location analytics are incredibly intrusive and worrying (for readers and writers), although some writers see it as useful.
- We need to be very transparent about any data it collects.
- We need to limit the data we collect to the absolute minimum required for analytics functionality.
Our next job is to answer the outstanding questions, then prioritise the function requests (I suggest ‘definite’, ‘desirable’, and ‘ditch’). Lots of factors come into play – which users they appeal to, how expensive and time-consuming they are to implement, and how much they represent ‘function creep’ away from the core principles of MacGuffin.