Coder Social home page Coder Social logo

opendataindex's People

Contributors

borysyuk avatar brew avatar diraol avatar johnmartin avatar ljoelle avatar morchickit avatar pacon avatar pwalsh avatar rufuspollock avatar smth avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

opendataindex's Issues

Implement Base UI on Bootstrap 3

Seeing as the new index templates will translated from Jinja > Liquid, there will be some amount of tweaking and enhancement in the process. This seems to me like a good opportunity to upgrade the base styles from Bootstrap 2 to Bootstrap 3.

Script to generate local data from Survey (live) database

Data used by the index will be stored as data files locally in the repo in CSV format (maybe JSON too if demand).

An executable script needs to be able to build these data files from the spreadsheet database of the instance.

  • First pass - entries, places, datasets, questions (as they were originally - no computation)
  • Entries cleaned up (yes, no, unsure, normalized, columns as we want etc)
    • Entries 2013 data
  • Places
    • Add slug field (should be in source sheet)
    • Compute rank, score, (percentage - score is percentage)
    • Compute isopen
    • previous score, rank etc, change in rank
  • Entries score / rank computation
  • Entries contributors computation (?)
  • Questions processing (yes count, no count etc)
  • summary (stats) table
    • summary table has per year info

Extras:

  • Entry timestamps need cleaning up to be iso 8601 (?)
    • Does this matter - we probably won't use the timestamps for anything
  • Normalize yes/no/unsure to Y/N/? in the backend (atm we normalize in code) (?)
    • Can live with normalizing in code
  • Add region to places (in backend census db - i.e. this sheet - #31
    • Move out to #31

Structure

What data do we have in the end?

entries.csv  # original entries probably plus contributor info
places.csv   # all places
datasets.csv # all datasets
questions.csv
summary.csv
Places table

id | name | slug | rank | score (out of 100) | [[ {datasetid}_rank  | score_previous | score_change | score_change_rank (most-improved) | rank_previous | rank_change | score_{yyyy} | rank_{yyyy} | ]]

Datasets

| original columns | average_score | average_percent | no_responses | 

Questions

| original columns | yes_count | no_count | na_count

Summary

| id | title | year | value | type (?) | details | (i18n values e.g. title@de etc)

e.g.

places_count, Number of Places, 249

Page for direct downloads of data

Add a dedicated page for direct downloads of data.

  • Section explaining licensing
  • Download all entries
  • Download entries by year
  • Download places (includes 2014_rank, 2013_rank, etc.)
  • Download questions

Implementation

Downloads will probably be direct downloads of the source data files. And/or, the API results. Alternatively, we could just provide zipped versions that are built when we build the other sources of the site.

Implement a chloropeth map for the global overview

A chloropeth map would provide a fairly instant overview of the state of open data in the global Index.

Especially with the new country additions, it would be easier to gain an overview of the current state of play, when compared to using the existing data table.

Site generation and local development

With current settings, the site is generated with > 4500 pages.

To create these pages, it takes Pelican about 5 minutes.

The file-watching dev server takes the same.

Without putting time into addressing this issue, my current strategy is:

  • Generate the site once
  • Remove the datasets, historical and places directories out of content/pages
  • Work and regenerate in a matter of seconds
  • When done (ready to deploy live output)
    • run python scripts/populate.py to get back the directories I removed
    • run the publish flow

This is far from ideal, but in practice, works quite well.

Action

Some possible solutions to this problem:

  • scope the live watcher to certain directories only. ideally dirs can be passed on command line so developer can just rebuild what is needed at will

Open Data Index datastore a valid Tabular Data Package

The Open Data Index is a static site, generated by Pelican.

It accesses Index data via a Pelican plugin written for the purpose, called datastore.

The datastore is simply a collection of CSV files, which are in turn a snapshot of the Open Data Census database + some post-porcessing.

The CSV files can be implemented with additional meta data to meet the Tabular Data Package specification.

Update theme for site

Re-theme site in line with old (or updated) theme

Additional questions: do we have a bespoke logo (of course based on OK one ...)?

What is the overall tagline / text logo we incorporate on embeddable stuff?

Implement ranking for countries in the Index

Ranking is implicit in the default view of the current "country" table: https://index.okfn.org/country/

Ranking should be made explicit, and used throughout the site (e.g.: overview pages per country).

It may also be possible and useful to provide additional ranking per dataset. This could lead to additional storytelling with the data (e.g.: "Denmark ranks in the top 5 on the Open Data Index, but when looking at Government Spending data, it falls well behind Russia, which is #30 in the Index.")

Setup for site translations

In code

  • Integrate babel for collecting translation strings, etc.
  • Check best way to write strings into our data soources ("[NAME]_[LANG]" or ....) Moved to #46, which will depend on okfn/opendatasurvey#485 in the Census codebase.
  • Integrate creating language subdirectories and pages with our use of Pelican generators
  • [X ] New project on Transifex for the Index

In data

See okfn/opendatasurvey#485

Individual Place Page - First Pass

This is a simple first pass - mainly copying over and checking we know how to do the jekyll. (Later we will do a proper redesign)

/place/:placeid

e.g. - note we use fullname as url ID rather than 2-digit
/place/australia

Implementation

In the place page index.html


---
layout: place
placeid: au

---

Then _layouts/place.html - cf https://github.com/okfn/okfn.github.com/blob/master/_layouts/person.html


---
layout: default
breadcrumbs: Place / 

---

{% include partials/data_glance.html place="{{page.placeid}}" year="2014" data_glance_class="row" data_point_class="col-md-3" %}

Scripting

  • Load entries.csv
  • Load places.csv
  • Walk through places and write out the stub files as above
    • Generate the url "slug" from the place full name (lowercase, underscore etc)
    • Save the ID into the stub file as placeid

Census entry form - "Title and short description" text not saved

The census submission form (for the OKFN Open Data Census 2014) looses information entered in the "Title and short description" field under the "Publicly available?" criteria.

Example: the "Title and short description" field is empty even though content was entered before the form was submitted: http://global.census.okfn.org/submission/0b992a16-9304-4d18-bf4f-78a6bea5a687

  • see comment at the URL above for the text that was originally in the form

Bugs & enhancements in data processing script

Bugs

  • There is a bug in the rank calculations after changing to support multiple year data in the process scripts. in place, I'm current just setting a dummy rank

Enhancements

  • For each place/year, build a list of reviewers and of submitters
    • What do we want to store? Just their name (or should we link to something e.g. twitter if we have it)?
      • Ans: only useful info we are guaranteed to have is full name so let's use that.

Write a localise function for datastore data

Data from the datastore plugin needs to be localisable (dataset info, questions, etc.). It can't be localised via the existing methods in Pelican. So, we need function to call on datastore data, when generating the site, to handle this.

To be clear, we have translation of strings in templates, and translations of normal "pages" in markdown, already covered with Pelican/Babel/Jinja etc.

Implement country score as a percentage

Currently, country score are a number, like "940" for the UK. It is not clear what this number means. 940/1000? Something else?

Country scores should be displayed as percentages, which are easy to understand (e.g.: "The UK tops the Open Data Index with 94% open data")

Move off gh-pages in order to provide an API to 3rd parties

GitHub Pages offers no way to configure CORS headers.

This means that the API we expose cannot be used by third parties (anyone calling the API from a different domain than the one that serves the API).

Amazon S3 and Google Cloud Storage both allow setting of CORS headers.

Seeing as we are not on Jekyll anyway, GitHub Pages is now just a place that we push built files too, so the difference between serving this files from GitHub Pages, Amazon S3 or Google Cloud Storage is negligible in terms of cost, development time, and ease of use.

These days, I use Google Cloud services rather than AWS (I like the tooling). However, I suggest we move to whichever one is preferred on the OK network.

Go live checklist

  • Google analytics enabled
  • License / terms of use etc
    • Standard ones in footer linking to okfn.org stuff
    • Plus: explicit statement re licensing of data and content. CC-By for site content and PDDL (but request to attribute) on data.
  • DNS for staging - staging.index.okfn.org with current site
  • CNAME for this site to using staging
  • DNS taken down to minimum ready for go live [now down to 10m]
  • CNAME for this site switched to index.okfn.org
  • DNS switched ...
  • Identify excluded countries in 2013 Index, and apply in build of this Index?
  • FAQ about possible discrepancies between versions of the Index (is covered in methodology)

Map View of Data - Analysis and Design

Info analysis / design of the (chloropeth) map

By default goes on the front page but can be developed as its own little module and included …

Ideas

  • Colour by overall score
  • Hover - what does it show
  • Do we want a multipurpose map e.g. allow colour by score on a specific dataset
  • Embed support
  • ...

Expose API endpoints

Generate API endpoints in JSON from Pelican.

  • Embeddable visualisations that are part of the Index site will consume these endpoints (e.g.: the chloropeth map)
  • 3rd parties can use the API for other visualisations/presentations of the data

Also note that the data directory has our raw data sources in CSV format, and could feasibly be used directly as an API (for example).

  • Write source files/extend the script that builds sources so that Pelican can output static JSON files on an API subdirectory
  • Implement endpoints:
    • entries (all years)
    • entries by year
    • places
    • datasets
    • place detail (all years)
    • place detail by year (will do if use case arises in visualisations)
    • summary - meta data like # datasets etc. (will do if use case arises in visualisations)

Bugs & enhancements in map vis

Bugs

  • Some strange behaviour on redraw of display when filtering the data: colours do not render as expected
  • query params for state not passed to embed
  • Can't close embed or place info from X button
  • link to share should be to home page

Improvements

  • Make OK ODI more prominent (logo, etc.)
  • Configure UI from params (e.g.: hide embed, hide toolbar, etc.)
  • Default embed config should be without toolbar (the suggestion is to only share a state of the vis, not the ability to use the vis with filters etc. on the embed) (Moved this for discussion in #47. Code to allow it is in place.)
  • Have a state to show score change from last year (a "most improved vis")
  • In the popup for data, show metrics for improvement from last year
  • Color coding: need less brown (many countries score 40 - 60)
    • Lower the resolution to 5 steps Adding a middle step to the scale in the yellow /yellow-orange range helps a lot
    • Add a point at middle which is either yellow or orange
  • Move all controls, actions and peripheral information to the bottom bar
    • Keep the top bar as a thin border above the map
    • New bottom bar
      • OKFN Logo, Open Data Index text
      • "Filter" button that, on click, opens a div upwards with the filter controls
      • "Share" button that, on click, opens a div upwards with the social share options
      • "Embed" button that, once click, opens a div upwards with the embed code
      • "Help or About" button that, on click, opens a div upwards with the explanation text (currently triggered by click on embed)
      • Small, simplified legend, with just two squares: [green (good)] [red (not good)]. further explanation will be in the "help or about section", but this will keep the map cleaner, and still provide the desired orientation
      • Default embed config should be without toolbar? (the suggestion is to only share a state of the vis, not the ability to use the vis with filters etc. on the embed)
  • Interactions on the map
    • On hover, track the mouse with a small info box, with only place name and score
    • On click, keep current zoom focus on country, and show data in box similar to now, but keep that data stable until the next click on a different place
    • Work a bit on presentation of this information box, and particularly on the "More information" link, which leads the user to the place page
  • UI
    • Move to a darker (like slate on OKFN site) background color for the vis box
    • I'm experimenting between a full dark background, and one where the "ocean" is a kind of flat blue that goes with the rest of the scheme - will see what looks best
    • Darken lines that define countries. On focus, do them less thick than they currently are
    • button to go back to global view
    • update the PLACE box when going to SLICE

Mini version (on place page for example)

  • place focus as param, so that place data is open, and see map context around the selected place

Documentation

  • Document the URL params

Branch management conventions for deployment

As raised in #21.

  • Add develop branch, for all development work (and to create feature branches from, etc.)
  • Use master as the branch to manage production deployments from
  • Add git hook that, when committing to master:
    • Runs pelican output with deploy settings
    • Runs ghp-import
    • Pushes ghp-import to origin (or some other remote name/convention if required)

Dataset overview page

  • One row (div or whatever) per dataset with Title
  • Link to dataset page (/datasets/{id})
  • Description (probably below)
  • [Maybe] Summary stats
    • Top Score (and Place)
    • Avg Score

As a user, I'd like to see the Index localised in my language

Using GitHub Pages, we can't use custom plugins in the automated build process.

So, any i18n implementation would require a local build before pushing to GitHub (would probably need a branch per language, and to deploy localised sites at {LANGUAGE}.index.okfn.org).

I see there are attempts at localisation in the existing code. I'm not sure if this is a consideration in building the new Index on GitHub Pages.

[META] Information architecture

Proposed information architecture for the new Index site.

Based on the existing implementation at https://index.okfn.org and new user stories.

Implemented

Outline

/  # overview page (probably the table or map - switchable possibly)
/place  # overview of places (??)   # may not have this as just the front page (??)
/place/:placeid
/place/:placeid/:datasetid
/place/:placeid/:datasetid/:year    # less important right now

/dataset/ # overview of all datasets e.g. overall stats .... 
/dataset/:datasetid
/dataset/:datasetid/:year (???)

# generic pages
/about
/about/methodology
/… 

# downloading data
/data    # maybe download 

Data discovery

The various routes/entry points for exploring the data of the Index.

Home

/

The home page should introduce the project and get right to the high level insights of the data.

The current home page has more of a focus on the mechanics behind the collection of the data.

Suggest to rethink the home page as a combination of https://index.okfn.org/ and https://index.okfn.org/country/. The current /country/ page is really the global overview, and this should be front and centre of the Index.

Country

/countries/{country_name}/overview

Similar to existing country pages, presents an overview of country performance (e.g.: https://index.okfn.org/country/overview/Australia/).

In addition:

  • Prominently show rank of the country out of total
  • Prominently show total % of openness
  • Show % increase/decrease in openness from previous census

Dataset

datasets/{dataset_name}/overview

Similar to existing dataset pages, presents an overview of dataset performance (e.g.: https://index.okfn.org/country/dataset/timetables).

In addition:

  • Prominently show total % of global openness for this dataset
  • Show % increase/decrease in openness from previous census

Country/Dataset

/countries/{country_name}/{dataset_name}/overview

Similar to existing country/dataset pages, presents a detail of this dataset in this country (e.g.: https://index.okfn.org/country/Australia/timetables)

In addition:

  • Improve position of "Data availability section" (always above fold?)
  • Show % increase/decrease in openness from previous census

Historical

/{current_pattern}/{overview}{year}

Now that the index will contain the data of more than one census, we can think about ways to show historical data.

At the simplest level, we can implement historical routes for all of the above routes: Country, Dataset and Country/Dataset.

As a special case, the "current" census, which is available on the "overview" routes, would have its year route redirected to overview (e.g.: /Australia/Timetables/2014 -> /Australia/Timetables/overview, if the current census is 2014).

Topical

/topics/{topic_name}

Topical pages transcend the base Country/Dataset paths for exploring data in the Index, and present additional ways of using the information.

Topic - Open data: What has changed?

/topics/change

An overview page presenting an analysis of change in the open govt. data landscape, as reflected by the Index, over the last year. Probably a combination of text, plus visualisations focused in displaying change, and linking through to other parts of the site.

Data export

Dumps of the raw dataset for download and further use. The data will be relatively static, but is subject to change on occasion if problems are reported in the dataset.

Suggest to have a timestamp of when the data was generated for the current build of the site, and include that as part of the filename for downloading data.

As CSV

/data/opendataindex_{timestamp}.csv

As JSON

/data/opendataindex_{timestamp}.json

Generic

General informational pages that support the core site.

Generic pages will never be generated from "data" in a build process. Rather, they should be fairly simple .md pages that are editable by content editors. If new generic pages are added, they should be discoverable on build and routed accordingly.

/{name}

  • About (about the project)
  • Contributors (list of contributors to the index)
  • Methodology (explanation of the methodology employed in creating the index)

Script to generate source files from data

In order for Pelican to build out the full site, it needs the appropriate source files in place ('source files' here refers to all files located under the content directory).

We require thousands of source files for an instance of the Index. The source files required are also dependant on the data that will be available to display in the Index.

Hence, we will have script that automates the building of the source files, designed to run whenever a new 'data snapshot' is made (#5) (new data in the data directory).

  • IF a view has no data, and we can accept submissions for data (i.e.: current year) show a suitable message and call to action (e.g.: no entry for "Australia/Transport/2014")
  • IF a view has no data, and we cannot accept submissions for data (i.e.: previous year) show a suitable message (e.g.: "Afghanistan" data in 2013)
  • places overview
  • place detail current year
  • place detail historical years
  • place/dataset detail current year
  • place/dataset detail historical years
  • datasets overview
  • dataset detail current year
  • dataset detail historical years
  • historical overviews

Visualisations - analysis and design

As far as I see, we have two main topics to discuss before closing on a development plan for visualisations in our current scope:

  • the ways in which we can present the data visually
  • how we can enable users to interact with and use these visualisations, on and off site

Ideas for visualisations / alternative data presentations

  • Table view: Basically, this is what is currently on the Index, with some small additions (filter by search, etc.)
  • Map view: Chloropeth map of the data. See here for spec: #15
  • Histogram / bar-chart of scores (rather than rank)
  • Sparkline style bar in the table to show position
  • Scatter plot against GDP ...
  • Error bars (??)
  • Others TBD

Enabling interaction and use

  • Data presentations to be embeddable
  • Data presentations to be stateful
  • Data presentations to be sharable

Technical requirements

  • Embed: additional routes for rendering visualizations without any site boilerplate; modular architecture for visualisation assets (html, css, js, img)
  • State: accept params on URLs to initialize visualisation states; push params to URLs with changes to visualisation state
  • Share: Sharing can be problematic with visualisations. For some networks (Facebook), we really need static images for a good sharing experience. TBD.

Questions

For any of the above:

  • Is it worth the effort?
  • Does it support our user stories?
  • Does it enable new user stories?

Implement core functionality of existing site in Jekyll

  • static pages
  • the main table for presenting data
  • Javascript interactions (assess on a case-by-case basis)
  • Various static text snippets on different pages - design as jekyll includes
  • info and visual assets in footer and header

QA: bugs/enhancements/suggestions

This is a meta issue to collect all bugs, enhancements and suggestions made/found in various other places.

Home Page

  • We seemed to have change summary at top from percentage to something else now
    • Get the logic (about make year to year comparisons better) but still think we want percentage somewhere

Map

  • How to read map - needs the scale we already talked about, better text
  • Logo next to title on map - make it transparent background
    • We need full logo (Image + Open Data Index) - can make it smaller. Also we need to decide on logo - do we have open data index specific logo or not (I've kept saying not but we atm logo at top of page is different. I recommend we go for standard OK image + Open Data Index text both at top of site and on map)
  • Move embed and share controls into the info popup panel? (instead of calling them directly from the toolbar - also use the words "EMBED" and "SHARE")
    • Is this deployed (not yet i think?)
  • Still have "Share and Embed" text in bottom toolbar (even if just opens same info box)
  • make toolbar size more consistent with rest of map border
  • title: (a) Open Data Index on top line, name of vis on next, and (b) place / dataset / year etc for title ("/")
  • logo in the toolbar: change to OK logo and name (and try the green)
    • but: green doesn't look good; and now with size adjustments to bar, I can't really fit the logo itself
  • Show full logo and title on the home page too
  • Map sometimes loads without data, causing weirdness
  • Share button on place popup?
  • Map embed iframe is set to 100% height but 'real' height is 360px so when reusing without much HTML knowledge you get confused about all the whitespace below the map.. for the country-specific one I'd suggest making the iframe size in the embed HTML the same size as the preferred size of the map on the country page itself.
  • In terms of the key for the map can we make the explanation of how to read the key/colours more obvious. When you hover over you get the following message: Colour represents the open data score per place of data for the current selection (0 - 100). Can we change 'current selection' to 'the dataset you have selected or the overall ranking for all datasets'
  • Map title - Does not look middle aligned with logo icon. Also should this not say: Open Data Index\n All Datasets / 2014 (i.e. we are missing the title of what we are seeing here)
  • Map functions on IE9
  • With the current projection, small places are lost (e.g.: Isle of Man) - consider a different projection? Moving to backlog for later reference if needed.
  • Map functions on IE8
    • Kind of works, but very slow, and some weird stuff
      • There is an issue with IE sometimes saying that a script is large and could cause the site to become unresponsive. However, all functionality works despite this. I'd say that it is not worth putting more time on IE8 unless a specific issue arises - users can definitely navigate the site and get info, even if the experience is not what they'd get on a more modern browser.
  • Countries that were not in the census in 2013 appear as 100% improved. this is not the case. the case is n/a for 2013 therefore this indicator can't be calculated.
    • We decided to leave this as originally implemented (n/a last year, and participation this year, is 100% improvement)
  • the embed link in map does not wrap on some browsers (FF ubuntu, some IE)
  • Regression - sometimes map data does not load onto map

Data

  • All places show max one reviewer and one submitter - can't be correct
  • All data is assigned to a year from the submit_year. This could be misleading as some data did not follow this pattern. compare timestamp with submit year and adjust entry year accordingly
    • Data team should look at this but not crucial for us
  • Change how rank is calculated: If 10 countries are no. 1 - the 11th should be no. 11, not no. 2
  • issue with computing openness - need to compare relative to the countries which are in both indexes (New summary stat: percent_open_with_last_year_places - compute open percentage this year with last years places) (only worth doing if you have spare time!)
  • Standardise formats: (e.g. all upper case for extensions, strip ","; normalise XLS variants to "Excel")

General

  • Table sorting is available on all rank, score and name columns - but need to make it obvious visually
  • Do we need to use the OK ribbon/show the OK logo differently in header?
    • No. Rufus is checking in general about changing the ribbon - leaving out of Index site for now.
  • Twitter share text is currently empty
  • On dataset overview, best performers are all 100%. Suggestion to instead, just say # places that got 100%?
    • I don't agree, I think how it is now is fine
  • On all 2013 pages, make it more explicitly clear that you are on a 2013 page (use it in heading, for example)
  • In tables, and in the top section of place pages, use arrows (up/down) to show performance compared to last year (user doesn't have to read so closely)
    • There is already a lot going on in the tables, and previous score is directly adjacent to current score, so the colour coding is enough IMHO to show the user that performance has become better or worse
  • All tables with format, also display if machine readable or not
    • info already exists on the row, as part of the icon set
  • Add name of submitter and reviewer to place/dataset pages (currently only on place pages)
  • On place and place/dataset pages, add "open" after the score, to make it explicit that the score represents openness (was there previously, I removed it)
  • Check sorting and display of rank on all tables - some of them are taking the default index sorting, but it is wrong in deeper contexts (like single dataset)
  • Christian (OS X Chrome; 1366x768) reports the social share buttons are not showing on place page. Weird - all work is done on the same spec laptop. Check it Cannot reproduce
  • Place/dataset page - why repeat the heading again in the middle of the page
  • Place/dataset page - fix alignment and spacing of text in bottom section
  • The new summary section on home page does not use the correct data/text
  • The "info" row toggle is great, but it is only on the place pages, not the dataset pages (e.g.: http://staging.index.okfn.org/dataset/statistics/)
  • Footer - take from current census as IS
    • links: add all the main navigation links, as well as others like methodology
    • licensing
  • Standard size for results in previous rank + score column
  • Bars in places table now out since column adjustments for sorting
  • % open on average (avg.) for datasets
  • # rank *dataset in index, on dataset pages
  • Add "Embed" pill with other social pills, and it opens a modal with embed instructions
  • Add dataset description in the empty space at top of dataset pages
  • On entry pages, show PLACE/DATASET in title. Probably always break on dataset, and align the "open" badge accordingly
  • Add "Open Data" badge from open definition.org under the open thing on our pages, when the entry.isopen
  • place/dataset # in the index FOR THIS DATASET
  • On entry page
    • don't use the main green for the URL and format badges - just bold
    • add the other new fields we have: officialtitle, publisher, license url
  • unjustify the details text on entry page
  • Fix alignment of text on entry page icon/question section
  • use question icons in the popups on places page
  • historical link as just text link
  • align historical and share sections
  • Remove "the following people..." phrase from contributor section
  • Check page markup for SEO - !!!!
  • On tables with a dataset column (e.g. place page), the dataset should have an info icon and a popup with the description of the dataset (see census site)
  • Ensure that ORDER of datasets in places table is consistent with their order in the spreadsheet
  • JS popup that requires email in order to download CSV/JSON (JS only, doesn’t stop direct access)
    ?
  • Link to Open Knowledge on in About page goes to http://staging.index.okfn.org/.
  • Write 'Global Open Data Index 2014' as the title to share on eg Facebook etc. (at the moment it's Open Data Index)
  • Do not show open data badge on country pages - only entry pages
  • Entry page: title on two lines; dataset first
  • "United Kingdom is ranked #15 for this dataset" - snippet under title on entry page
  • Alignment (width) of Open Data bade with % open "badge" (fix width on % open badge too)
  • See about (a) moving % open back up, or, (b) fixing the alignment with the rank snippet
  • "Share or Embed this page"
  • Move share feature back as big line at bottom of section, as well as inlining the years thing
  • Changes to entry page:
    • Remove about heading
    • First thing here would be: "What data is expected?" and then have the short description below. Then below that we have heading (same size): "What data is available". I would then actually have the url, format attributes. Then below that have the Deos the Data Exist stuff from RHS. Then in parallel div to right lets' have: "Details" (probably just bold or maybe a minor heading) then all the text.
    • Show full list of attributes, even if n/a (officialtitle etc), Remove bullets from list
    • Remove bullets on questions.icons list, and left align it as per discussion
    • Check markdown on the details of entry
    • Fix text indents as relevant
  • Fix wrong icon in header
  • Add OK logo in map (get a favicon version or something)
  • Stories section
    • Style fixes
  • use black/white OK logo on map bar
  • Change the text 'See other years' to 'See previous year' (this can be changed again next year)
  • Add back links to datasets from the places overview table headers?
  • Should we explicitly mark places that are new in the Index? (on tables, on their place pages, etc.)? added to backlog
  • Do we need to return to having percentage on the home summary section - how? not in scope right now
  • The tables are not responsive (even though they have a responsive class applied) moving to own ticket
  • when you click on icon machine readable the info-box opens - there the file names don't fit in the grey squares (any dataset list page) Moved to own issue
  • markdown parser is spec compliant, and does not auto URLize url strings. Needs an extension (or i'll write one)
  • the scrolling header on tables has a small rendering issue on first few rows of scrolling added to backlog
  • Width on story index and story article pages
  • float on story images
  • global open data index stories as story headline
  • remove Global open data.... prefix from each story title
  • fix heading links on stories so it is more obvious that they are clickable
  • Add a "read more" button under story snippets on the index pages
  • email to [email protected], and [email protected]
  • place page bug where the sort icon appears on non-sortable headings
  • Add info icon next to dataset name in place page table header, where popup is dataset description, and link to dataset page
  • "percent open" have a * with a popup that explains: This is the percentage of all the dataset entries that are open as per the Open Definition. We get one dataset entry for each dataset and place (e.g. Transport Timetables for the United Kingdom is one dataset entry). For each entry we can check whether the dataset is fully open as per the Open Definition and then divide by the total number of entries to get a percentage. [Find out more about Open Data => Methodology Page#open-definition]
  • Make numbers (place + number open) on front page link somewhere (probably place page)
  • map icon > name spacing [minor]
  • Add back improvement filter
  • Create Contact Page /contact/
  • Move press info there from press page
  • Create Open Definition section on methodology …
  • remove bullets from table popup
  • bug in online link

new Place page layout

Based on this UI mock

Mini map vis

  • data should be visible at all times
  • data should show improvement from previous year metrics
  • OK ODI logo
  • Show country context by default

Visualize data on a map

Based on spec in #15.

Implementation progress

  • build the basic generic widget for embeddable visualisation
    • share to: twitter, google+, facebook
    • grab an embed code
    • area for licenses and attribution
    • area for links (project, main website, etc.)
    • area for data tools (filters, etc.)
    • area for data display (map, etc.)
    • area for visualisation legend
    • dynamically resize all elements according to the parent container dimensions
  • Implement an embed view for the visualisation
  • Implement a permalink view for the visualisation
  • Integrate the embeddable visualisation into the home page
  • Integrate the embeddable visualisation into the place pages covered in #40
  • Implement color scale for the legend
  • Implement Leaflet.js for the base map background
  • Implement API calls to our own API to get: places, datasets, entries and meta (summary) data
  • Bind meta.years and datasets to selector widgets in order to filter the visualisation display
  • Apply the filters to the visualisation display and re-render on change
  • Accept URL param args to the visualisation to initialise state
  • Integrate world geojson and overlay the world map with it, color coded per country to the color scale
  • Click on a place to (a) zoom it forward and center; (b) show the place data overview
  • Hover for a few seconds on a place to show the place data overview
  • Place data overview with summary of the place and link to place page
  • When embedded, scale width and height dynamically?
    • No - the developer who embeds is responsible for managing the iframe size
  • Use require.js to load scripts as modules, and to build a single dist script for deployment
  • Test on Firefox
  • Test on Safari desktop
  • Test on Chrome
  • Test on Safari mobile
  • Use real data with the visualisation instead of mock data (will happen in #5)
  • Test on Chrome for Android #33
  • Test on IE8 + #33

Bugs will be treated in #41.

Table view of data - improvements

Bugs

  • Color coding of "Score" cell - couldn't get the chroma.ColorScale constructor to work
  • Adjust display of elements for responsive (important for on site, and potential embeddable version):
    • show/hide certain cells
    • width/height of availability indicator
    • angle of header transform
    • font size on certain texts

UX

  • Improve display of "Tools" and "Key"
  • Allow semi-colon separator in search box to provide multiple arguments
    • e.g.: "island;state" - would match all countries with either of the strings "island" and "state"
  • Additional sort tools? ("#Yes" sort was just added as an example, it is probably not useful)
  • Add score change column (from previous)
  • Add rank change column (from previous)

Implementation

  • Refactor assets (html, css, js, img) so that the visualisation is modular (prep for embedding)
  • Initialize state of view with URL params (?search="island;state"&sort=score) removing this now, until it comes up as a feature for someone
  • Markdown rendering do we need it client side?

Questions

  • pros/cons of loading data via XHR call (like on existing Index), rather than rendering the initial state on server (like in the new implementation)

UI/UX review & discussion

@rgrp @johnmartin

This issue is a place for any and all notes/comments on UI/UX.

I think we'll try to keep everything in list form, organised by area/feature of the site. The initial list comes from things discussed by John and I today, and by Rufus and I yesterday.

@johnmartin I extended on some things. Please have read, and add/comment for anything I may have missed from our talk.

Note that this list is also after John's main work on theme implementation, so please refer to it:

Header

  • Add a direct link to the Places overview table?
  • Is the visualisations link at all useful?

Footer

Generic elements

Tables

  • Fix header in place
  • Some icons do not show as they come from the database and there is a mismatch between font awesome 3 and 4 (3 is used on Census, 4 is used here on Index)
  • New change column does not show correct info
    • Do not bother with change column in table atm

Home page (http://staging.index.okfn.org/)

Place page (http://staging.index.okfn.org/places/gb/)

Dataset page (http://staging.index.okfn.org/datasets/timetables/)

Place/Dataset page (http://staging.index.okfn.org/places/gb/datasets/timetables/)

  • Fix - it currently renders the same table as a normal "dataset" page would.

Place overview (http://staging.index.okfn.org/places/)

Datasets overview (http://staging.index.okfn.org/datasets/)

Currently identical to Place overview

  • Remove it?
  • Treat it differently?
  • Tables on datasets!
    See #57

Icons for datasets

Nice if font awesome had them but may need to use the noun project or similar (and store locally in e.g. assets/icons/)

Pelican vs Jekyll

Jekyll pros:

  • Just can push gh-pages branch (no need to build and store)
  • People an edit (some) content live and deploy (no need to install)

Pelican pros

  • Excellent templating language (syncs also with main app)
  • Python based (we like python)
  • Better internationalization if we need it
  • Downside of static build is less since we need to import data and then build out pages anyway ...

Conclusion: seems like pelican is a good idea ...

UI/Design enhancements

Placeholder issue for implementing a launch able UI for the new Index. Depends on #37.

Enhancements:

  • For the summary data (# open, % open): show a section on the front page that displays change from last year (suggestion: last year figure bracketed next to this year?)

Request: Create separate Pelican datastore plugin

Was looking around to see if anyone had ported Jekyll's Data Files functionality to Pelican, and found that you have a datastore plugin.

I was wondering if you'd consider both:

  1. Creating a separate repository for this code, and
  2. Submitting it to the Pelican Plugins repository

So that others can benefit from this. The code looks like exactly what I'm looking for.

Thanks for your consideration.

Thomas

Home / Overview Page - First Pass

Just a first pass:

  • port over the current sorting table … (largely to test we can do this)

Do not too much more as we will likely redesign a bit

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.