August 22, 2017 IDRC Design Crit - Storytelling Tool

Discussion based on these wireframes and the current implementation of the tool


  • We don't have many alternate modes in the design yet, working on speech to text, adding images, will eventually include video, ASL ...


  • A story summary is a short 1 or 2 line summary of the story
  • Share vs save without sharing
    • Share = publish to collection
    • Save without sharing = store it but not publish it, maybe for editing

    • Upon save, goes to the story in its published form
  • Read another story like this
    • Finds another story with similar tags
  • Next story goes to next story, alphabetically


  • how to handle/structure/create categories? 
    • easiest way is probably to require the user to choose a category or categories from a limited set for each story (like Youtube, except we needn't limit it to one category)
  • combine this with free-form tags to allow more flexibility in choosing descriptive and unique theme tags
  • Is it better to have a search field at the top of the main screen?
  • Results page
    • If there's no summary provided, show the first couple lines of the story
    • Scroll through the results


  • should we allow users to edit their stories?
    • yes, both their own as well as allowing collaboration/remixing between users
  • how do we deal with translations and editing?
    • would have to use versioning to keep track 


  • User can request a manual translation to a certain language
    • They will be notified when a translation is provided
    • Request tag shows up under language tags
    • Should we allow multiple requests? (i.e. count how many people have requested it)?
  • Can have it autogenerate a translation
    • should this be temporary or persistent?
  • User can provide a translation to another's story
  • probably want to have the original story text persist on the screen while doing a translation (rather than editing it directly in a single field as it's shown now)
    • perhaps have this on a separate screen of its own
    • check this with someone who does a lot of translation work
  • what about starting with an auto-translation and then allowing editing from there? could be an option
  • want to be able to check and edit the auto-translations (even for single words or phrases such as theme tags)

  • Autotranslation: review it before 'submitting' it?
    • Should it be persistent?
    • Should it even be offered?
    • Should it be presented alongside the 'listen' button, just a temporary machine translation
    • Chrome will offer to do this on its own already
  • The manual translated ones could be listed and then a button for auto
  • Offer the auto-translate options to viewers of a story as well...
    • How?
  • should we provide translation as part of the authoring/editing environment at all? maybe better to just offer it in the story viewer
    • maybe “view in another language” offers translations that have been done manually only?
    • and/or auto-translations are dropped directly into an editing interface?

  • what about translating the theme tags?
  • or do we keep them as-is in the language they were added? 
    • we need to translate them to facilitate searches in multiple languages (or can users rely on the search engine searching through content and titles only?)
    • we can use auto-translate, but this is still problematic especially for multi-word tags and phrases


  • the TTS engine needs to know the language of the story in order to choose the appropriate voice (when activating "Listen to my story") - so choosing the language of the story needs to happen on the first screen
  • how does this relate to choosing the language of the interface? we can’t assume that the language of the interface is the same as the language the story is written in (especially when a user is translating a story)

  • language drop-down - want to include an “other” option for any languages that aren’t on the list
  • we should include language locales too (i.e. Canadian English)

And discussion of the questions listed here:

  • Tags vs categories?
  • If you have so many categories, would you enter the same info as tags? Overlap between them
  • What would be the effect if there are only six categories but you add one of them as a tag? (or not)
    • It would depend on how we implement the browsing/searching
  • Why do we need categories if we have tags?
    • It's a way to search in a different way, a preset list of keywords
      • Could maybe give a list of tags
      • Most popular ones? Most recent ones? A sample pool of them
      • Categories let user search more broadly and offer a bigger picture of what's available 
        • Tag cloud favours certain ones over others
        • We would be limiting the user if we take away that variability
      • Search for "Friend", "Friendship", "Friends" etc, if it's just tags, there's duplication
      • When tagging, maybe we could provide autocompletion
      • (this sounds like the common terms registry)
      • Instead of categories, just suggested tags?
      • Common approach in systems that allow free-tagging is to scan the user input and make suggestions based on that
      • There's a tradeoff in that free-tagging results in more but lower-quality metadata, but a fixed category system is less useful but higher-quality data. Machine-driven solutions are not very good at this point
      • If you crowdsource your metadata without a person behind it, without cleanup, the quality is less than good
  • If we have lists of tags and categories that are mutually exclusive enough from each other, it's helpful, but it's complicated to do it right. We might get better-than-nothing metadata, but it may not be great
  • Are we translating the tags?
    • We may not need to, depending on how the search works
      • If it searches over content too, this works well
    • Auto-translate them?
      • Not all single words auto-translate properly
    • Multi-word tags?
    • Provide the user with an option to add tags when doing translations?