functionalities document 3

FUNCTIONALITIES

Functionality document – The Future of Publishing 2

The Future of Publishing

MediaLAB Amsterdam

Create-IT Applied Research

University of Amsterdam

Version 3

Functionalities document

Monday 23 April 2012

Project manager

Margreet Riphagen

Team

Elin Wassenaar

Arelina Merakou

Lars Böhm

[email protected]

medialab.hva.nl/futureofpublishing


Table of Contents

1.0 Functionalities for the front end ........................................................................ 4 1.1 Must have....................................................................................................................................4 1.2 Should have ..............................................................................................................................6 1.3 Could have .................................................................................................................................7 1.4 Will not have ............................................................................................................................8

2.0 Functionalities for the back end......................................................................... 9 2.1 Must have ...................................................................................................................................9 2.2 Should have ........................................................................................................................... 10 2.3 Could have.............................................................................................................................. 11 2.4 Will not have......................................................................................................................... 11


1.0 Functionalities for the front end

The MoSCoW method is used to divide all the options into four categories: must have, should

have, could have and won’t have. It is a hierarchy of priorities. Must haves are core

functionalities; without them the product wouldn’t function properly. Should haves are

functionalities that are highly appreciated, whereas could haves are nice extras that are not

entirely necessary. Won’t haves are self-explanatory.

1.1 Must have

• There will be a table of contents.

The page will show headlines, with the most interesting articles displayed

on top and bigger than the other articles. The other articles will always be

displayed below the headlines in accordion-style format.

• There will be a table of contents dropdown when reading articles.

By tapping the table of contents-icon, the user can access the table of

contents. A dropdown with a list of articles (also accordion style) will be

shown, but the user will also have the possibility to go back to the table of

contents page.

• The user must have the ability to leaf through pages.

By swiping, the user can navigate to the previous or next article.

• Sharing options.

At the end of every article, icons for sharing on social media (e.g. Facebook

and Twitter) will be visible. By tapping them, the user can share articles on

social media.

• Searching should be possible on individual articles as well as the magazine as a

whole.

Tapping the search button will open a dropdown overlay where the user can

enter a search term and choose to either search the entire magazine or the

current article.

• Ability to display images and videos full screen.

No further explanation necessary.

• Minimum loading times.


• Room for ‘asides’ in page interface design.

Asides will show e.g. quotes and extra information


• Expanding/Spread.

By moving two fingers away from each other at one point in the

magazine, the text/page will be enlarged or the

image/video/data visualisation will be displayed full screen.

• Pinching.

Pinching will return the text, video/image/data visualisation to

its original size.

• Tapping.

Tapping a button will activate the button’s functionality, or when

tapping a picture, it will be enlarged.

• Scrolling.

By scrolling the user will scroll down on the page – articles are

not subdivided in different screens, so the user can scroll down

as little or as far as he/she wants.

• Discoverability (inform the user where to find content).

There will be a scroll bar to show the user how much of the article

he/she has read. It will only be visible when the user is actually

scrolling.

• Clear indication of content.

There will be icons to indicate what kind of content something is:

images will have a different icon from photo galleries and it will be

indicated when something is a video or data visualisation as well.

• Reliability.

We will try to make sure the user doesn’t accidentally activate

something that he/she doesn’t want to activate, by looking at the

optimal size for tap zones.

• Back button.

Activating the back button brings the user back to the previously viewed

page.

• Menu.

In the bottom left corner, there will be space for the navigation buttons:

search button, instructions, back button and table of contents button.

• Article numbers should be visible while browsing the magazine (or in metadata?).

Expand/spread

Pinch

Scroll

Tap


The user should always have some indication of the place in the magazine.

Article numbers could be visible as ’15 of 32’, for example.

• Changing tablet orientation (portrait/landscape).

The option to read both in portrait and in landscape orientation should be

implemented.

1.2 Should have

• Cover or a front-page (headlines).

A magazine cover or front page with hyperlinks to the articles in the

magazine should be available.

• Editorial.

There should be an editorial in which the lead editor gives an introduction to

the magazine.

• Each article should specify its length.

This can be done by showing the amount of words in the box with metadata.

• Instruction page.

There should be a page instructing the user on how to use the interface and

explaining which gestures can be used for navigation. This instruction page

can be accessed by tapping the (?) button. It will be located after the cover

page.

• Help button

The (?) button redirects the user to the instruction page.

• Information button

The (i) button will present the user with metadata from the article, e.g.

amount of words, tags, date of writing. It will be shown next to the

title of the article within the table of contents as well as on the content

page.

• Press and hold. E.g. text selection. This would give the user the possibility to copy text,

highlight text, make a note and look up words, for example on Google or

Wikipedia.

• Header.

A header with the magazine title, issue number and article number should

be available. It will be transparent and stick to the top of the screen.

• The user should be made able to make annotations in the articles.

Press and hold


The user will select a word or an excerpt from the text, then select the option

‘note’, which will bring up a pop-up. In the pop-up the selected text will be

displayed above the box where the user can make a note. The note will be

linked to the text, which means that when viewing your notes, you can be

redirected to the part of the text that the note connects to. The separate notes

should be made sharable.

1.3 Could have

• Dog-ear style bookmarking.

The user will be able to ‘dog-ear’-tag a page, to which he can be redirected

upon revisiting the magazine.

• The platform could include an archive to view older issues.

The user will be able to access this archive from the ‘options’ button in the

navigation bar. The archive will be structured like the table of contents.

• Independent of Internet connection.

The app could be made available for offline use.

• The user’s annotations could be accessible from other devices as well.

The combined notes from the entire magazine could be made sharable

and/or accessible with other devices as well, for example by using Evernote.

• Back cover.

The back cover would show that you are at the end of the magazine. It could

contain a preview of the next issue, or it could be the colophon page, or just

show an image.

• Footer.

The magazine could have a footer, where the social media sharing icons

could be situated.

• A way to subscribe to future editions (free).

There could be an option to subscribe to future editions, e.g. on the back

cover.

• Canvas-style overview

The overview could also be presented on a canvas, where the publisher

could create a network of articles, or use a map or timeline to present the

articles in a different way than as simple text.

• The magazine could have a designated e-mail address

The magazine could have a designated e-mail address which the reader

could use to e-mail magazine-related questions to.

• Colophon page.


The colophon page will contain several fields, which will list all those who

cooperated on the magazine.

1.4 Will not have

• In-app payment system.

• User-generated content.

• Active social media features.

• Space limits.

• Carousel scrolling.

• Page slider navigation.

• The user will not be able to change font sizes and types.

When first using the app, the user will be asked for his/her preferences in

font, font size, line spacing and colour. This option would also be available

by tapping the Aa-button. However, after the user testing, we found out that

users want to read a text as it is presented to them by the publisher.

• Page viewer style navigation.

Shows the user an overview of all the articles. After the user testing, it was

clear that we needed only the table of contents for clear navigation.

• Options button.

The (+) button could be used to access other buttons and functionalities.

Since we decided to go with a very simple interface with only the necessary

buttons, the options button was no longer needed.

• Home button.

The home button will not be available in this application. After user testing,

we found out that people didn’t know where the button would take them and

for the University of Amsterdam, an archive is not important because their

magazine will only be published once a year.

• Top and bottom navigation bars.

There will be no navigation bars. Because several buttons were taken out

after user testing and because it is more easy for the user if the important

buttons are always visible somehow, the menu bars are no longer needed.


2.0 Functionalities for the back end

2.1 Must have

• Customizable magazine title.


• Multiple authors must be able to edit, access and publish on the platform at the

same time.


• Text publishing functionalities.

There will be a basic text-editor.

• Image publishing functionalities.

Images can be uploaded and are automatically rescaled for publication in

an article.

• Video publishing functionalities.

Video can be uploaded or linked to and will be automatically rescaled for

publication in an article.

• Audio publishing functionalities.

Audio can be uploaded or linked to and will be available in a standard-sized

audio player.

• Ability to publish interactive content.

For publishing a timeline or interactive map, a template will be available.

For publishing a data visualisation, there will be an ‘empty’ template where

the author can put in HTML5 or Javascript.

• Several page pre-sets

There will be several page templates available for publishing content.

Cover-page, table of contents, editorial, content-page, colophon and possible

back cover, video page.

• Hyper texting functionalities.

Hyperlinking to other types of digital media.

• Searchability for the publisher.

The publisher will be able to search the back end. This search will include

published and non-published articles.

• Media library.

This will give the publisher an overview of the different kinds of imported

media.


• Parent/child categorisation of articles.

This is necessary for the table of contents.

• Creating an excerpt.

The excerpt will be used in the table of content and under the (i) button.

• Possibility to add a logo.

The publisher must be able to insert a logo for branding purposes.

• Possibility to edit after publishing.

The writer must be able to edit the text after publishing.

• Possibility to add asides to an article.

Asides can contain quotes or other extra information.

• Easy to use back end interface.


2.2 Should have

• There should be a form of branding (static or dynamic).

The publisher should be able to edit style elements.

• Possibility to add tags/keywords.

Adding tags and keywords to an article improves visibility in the search

functionality. Tags and keywords also provide a simple summary of the

contents of an article.

• Possibility to create an interactive map or timeline.

There should be some standard format to create these features that will

either be a part of an article or they will stand-alone.

• Different contributors to the magazine should have different roles.

Editors will have different levels of access to editing, for example there will

be an administrator, editors and authors.

• Headers

The publisher could be able to add a header to the pages in the magazine.

• Editor profile.

Automatically add author name to the article, colophon and extra

information.

• Metadata input

The publisher should be able to add the extra information needed for the

metadata button.


2.3 Could have

• Design templates.

The publisher could choose from different design templates.

• Update log.

The publisher could always see in the log of updates when what was edited.

• Designated e-mail address

The publisher could add a designated e-mail address, which readers can e-

mail to.

2.4 Will not have

• Contact form.

functionalities document 3

Documents