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

Admin v2

Will ember need new endpoints in V2 JSONAPI that don't exist in V1?
What are the routes moving from angular to ember?
Will route changes impact the existing authentication scheme?
Are these all the pages/forms that will transfer from angular to ember?

• "Manage Sites"
• "Organization Info"
• "Import DCAT Data"
• "Create new site"
• "Site configuration"
• "Capabilities"
• "Group Manager"
• "Data manager"
• "Site Editor"

Will any page functionality be removed or added in the process of migrating over to ember?

Custom domain authentication options?

Good job capturing all the things.

One other thing (that I already had working but got pushed aside in the last minute shuffling) was to have our local dev environments for -admin (and possibly -ui) be as similar as possible to the dev/qa/prod enviroments:

• serve locally under HTTPS
• use same locationType ('auto' instead of 'hash')

@tomwayson If you haven't already, you'll want to speak with Daniel. He's dockerizing the entire OD stack. If this is something that's needed, it should be incorporated with his work.

Regarding the accordion: http://jsfiddle.net/Tcgyx/15/

Regarding "Fix issue w/ css relative paths breaking in prod-like builds": ember-cli/broccoli-asset-rewrite#36.

Regarding "status.json build so we can tie ui version into the Open Data status page (98% complete)": this is GTG as an in-repo addon in opendata-ui - we just need to extract it into its own repo and npm install & configure it.

Regarding rendering the 404 page but retaining the url: I think we could use renderTemplate; https://guides.emberjs.com/v2.6.0/routing/rendering-a-template/.

Regarding the form validation. We use ember-cp-validations in opendata-ui (for the signup form). It can be used with components but I have an inkling that ember-stickler will be a better fit for the peculiarities of the admin app.

Update: I have been playing with ember-stickler this morning and I definitely like it. I have a couple of outstanding questions that I am trying to resolve.

Update2: ember-stickler does not support async rules as far as I can tell. I have been trying to find a way to get that functionality but thus far have been unsuccessful. I'm going to pursue this a bit further but I think that's a showstopper if I can't find a good way.

Update3: They say it is possible (sethpollack/ember-stickler#5). I have found a way but I don't know if I love it.

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.