Open Data Front-End Plans July 2016

gistfile1.md

Open Data Front-End Strategy

July 2016

Sites / Layout Issues

• lets put this on hold for a sprint
• get feedback and tackle UX issues systematically vs rushing and guessing

Layout Issues

• the current system for isolating the Layout Editor from the Layout CSS is not working correctly and needs to be re-assessed
• Footers! Footers need to be "extracted" so they can be rendered on any page, not just the Home page of a site.

Lingering Issues from "Connecting the Dots"

• "Gear icon” should be gray like sidebar header
  • Flip brand primary and link color defaults in Theme Builder (link = blue, brand primary = gray)
• Make entire accordion row clickable (not just the name “Theme Builder”)
• Add hyperlink from 'Data Manager' in error to actual page on category card.
• Empty Row should have button/link that opens side-panel w/ Layout Builder section opened
• Work out the interactions around:
  • start dragging widget onto page (hide side-panel?)
  • drop widget (show side-panel w/ widget settings open?)
• Card-Resizer should use buttons not 's so the click targets are better
• When Banner <h1> is empty, do not put element in the DOM
• When Banner <h2> is empty, do not put element in the DOM

Priority Tech Debt

• Fix issue w/ css relative paths breaking in prod-like builds
• local devt under https
• local devt using locationType:auto
• status.json build so we can tie ui version into the Open Data status page (98% complete)

General Code Cleanup

• move all services into the /services folders in the apps
• extract shared services into ember-arcgis-opendata-lib
• deal with https issues for glyphicons in the layout editor
• replace all col-md-XX in components with col-xs-XX or multiple classes
• what can we do so we retain the url, but show the 404 page (per https://github.com/ArcGIS/composer/issues/9118#issuecomment-228243223)

Unified Site Model / Adapter

• move Site model to ember-arcgis-opendata-lib
  • bring along the adapters & serializers for now
• move Page model to ember-arcgis-opendata-lib(for consistentcy)
• Update opendata-ui to use the site model
  • if !window.__SITE || window.__SITEID then fetch from API

Pages

• we need to create a "pages" version of the site-editor component so we can swap in/out the component editor UIs
• create a service to CRUD Page --> Application Configuration item @ AGO
• start investigation into storing images and other assets w/ page @ AGO
  • i.e. json that is the summarized data for a chart, so it loads REALLY fast

AGO Item Service

• Ember friendly utility that does CRUD for items using fetch
• Ember services for Pages, Sites etc will be built on top of this
• see if we can use node-arcgis but don't get hung up on re-use.

Admin v2

General plan is to move the current Admin v1 functionality to Ember quickly, while at the same time streamlining the information architecture.

Information Architecture Changes:

• Move "Data Manager" up to be a top level concern vs under "Site"

We need to review any Admin UI v2 wireframes that Klara or Erich have, and decide what if any of that we are using. We also need to formalize and standardize our form validation

• jupe is digging into this and will have a decision by Wednesday 6/29
  • ember-cp-validations seems to work at the model level, but our editing UI's are not 1:1 with models
  • ember-stickler seems to be more focused on validating a form Github

Well I'm really kind of at a loss here...

ember-cp-validations

Pros:

1. Much better documentation
2. Support for async validation rules out of the box
3. We should be able to achieve smooth I18n integration with https://github.com/jasonmit/ember-intl-cp-validations

Cons:

1. Not very user friendly for form validation which is what we want to do. This seems to be particularly true when used at the component level. Though it does have a sample validated-input component in the dummy app which inexplicably doesn't actually ship with the addon.

ember-stickler

Pros:

1. Geared specifically towards form validation and seems to work well at the component level.

Cons:

1. Async validation rules (which we need) are not explicitly part of the addon. However this issue implies that it is "easy". I have found a way to make this work but I'm not sure it's good.
2. Poor documentation. The sample code in the readme does not work as-is.

I guess if I've got to make a call I'd say ember-stickler but perhaps @dbouwman and @tomwayson would like to weigh in.

I would also very much like to get opendata-ui assets cloudfronted. I am pretty sure we can do so without any ops help.