100% Sport

These are my current thoughts regarding the design of 100% Sport.

They are subject to change.

Maybe today ☺

In article view of statistics

  • Single statistics view
  • Ensure easy access back to article through modal windows / sliding panes
  • All drilldown possibilities is possible in the table
  • Links to full statistics centre. The link should keep state from modal window / pane


Small screen

  • Statistics slides in from right. Article slides out left
  • Link back to article in top in the navigation area


Large screen

  • Modal window over article
  • Link back to article through close button


Tables

  • All data should as a rule be linked to underlying data.
  • Exceptions for data linking back to the same table and non-data (if such thing exists)
  • Values/fields should be rule based to avoid having to author each table and to ensure an automatic tooltip
  • Tables should contain embed and share codes
  • All columns must be sortable.
  • Tables to large for the current viewport width should be overlayed with a “Table to large for the screen. Click to view the table on a new page” – or something more clever.



Statistics centre

  • Automatic layout based on most popular statistics
  • Navigation area to different sports. (Navigation is shown as a tree view. This is my opinion right now and I will discuss this with Bartosch.) Most popular is most prominent.
  • Tree view expands on each sport to show most relevant tables. (Here we must discuss how to decide on that)


Widgets

  • All widgets should have to possibility to be loaded asynchronously. Some core widgets might need to be rewritten.
  • We don’t create platform specific widgets. Every widget should work on all platforms.
  • Minimum footprint for unloaded widgets.


Connection

  • We need to measure the bandwidth of the end user precisely enough to establish connection type (3g/Edge)

CSS

-    New grid.

  • Should be written from small to large. Desktop styles is in media queries
  • Breakpoints will be given later.No mobile/desktop css-files. Instead files based on viewport width. For instance below 601px the widget-[controller]-[view]-600.css is loaded.
  • Below 981px both the widget-[controller]-[view]-600.css and widget-[controller]-[view]-980.css is loaded

Design

  • Every link and button must be touching friendly. This means they should be large enough for a fingertip. We will feature test ouch, but we should still ensure that we create a design that is directed towards touch interfaces.
  • Widgets from statistics and live should not contain branding.
  • We will feature test touch and add classes to the body element. If touch is present we should use touch conventions and visa versa.
  • Logos, fonts, borders and colours will differentiate between publications.

 

DesIGN

  • Sports icons will be identical between publications.
    We will create special widgets for our most popular sports. One example of this is the “player card”. We should still aim for a generic approach for these widgets.

Design

Layout is adjusted to the viewport width. This will have consequences to the possible options for rearranging widgets across platforms. We have three options.

  1. Placement is decided by a single widget placeholder element in the html.
  2. Placement is decided through named groups in the html and each widget can be configured to go to different groups for different viewport widths. This only concerns widgets that are asynchronously loaded. Javascript will adjust the visibility when the resize event is triggered.
  3. We desk several widgets and equip them with fields or classes that decide on the widget visibility for different viewport widths. Javascript will adjust the visibility when the resize event is triggered.

Ads

  • To strategies for ads: Responsive and multiple versions (small, medium & large)
  • Templates supporting both need to be created
  • We need to establish a common framework for html-ads across all Norwegian media houses. This is to avoid multiple instances of for instance jQuery, Video-code etc.
  • All ads must be sandboxed. If they are not sandboxed with iframes, we cannot allow third party ads.


Configs

  • One common config for all platforms.
  • Visibility of widgets should be decided through a priority (decided by bandwidth) and viewport width. Javascript handles loading of widgets.
  • Templates need to be modified with a priority class


Minify

More minify-packages should be created due to priorities and viewport widths.

 

Images

  • My current opinion is to test if Mobiletech can deliver to desktop. Image widths is delivered by reading the user agent database
  • Other option requires all images to reside on the same domain as the site. If we do this, we can use a base tag.
  • Other options are cookies, but this might give wrong results.
  • I suggest we invest a few days to explore possibilities.


Last words

I urge you to follow the coding conventions for front end. If you do not, make sure you are not around when I find out ;-)

Made with Slides.com