Strategy for ACA Short Term (8.0/8.1) – Focus on UI changes. No major enhancements. – Customer Commitments / Bug Fixes. Long Term (2016 and so on) – Rethink existing features – Find a better balance between customizability and UI/UX control – Leverage new AA architecture

Short Term (Approach) Maintain functionality, do not introduce new features. But make a cleaner design. Review ux flow on a case by case basis (for ex. adding accounts/addresses), take the low hanging fruit but defer to new ACA.

Short Term (Deliverables) Home Page – Restyle homepage. – Allow iframe to respond to device width Internal Pages – Restyle search results page – Restyle record display page Forms – New design of standard controls. Change markup to accommodate responsive design – Restyle Page flow navigation – Styles per container in page flow Remove Silverlight dependency

Not so Short Term (beyond 8.1) Performance (from three contributors) – API (mostly an AA dependency) – EMSE fired on form (need to look at feasibility of migrating EMSE functionality into AA itself) – Page Rendering (page size and markup complexity) Migrate to new AA REST API “Global” Search – Consolidate search using Elastic Search, but first we need to fix Elastic Search CivicID integration

Short Term (Risks) From a technical point of view: – Clear path for 8.0/8.1 – UI changes will be tricky but we understand the problem and what needs to be done Risk: – These changes are design-centered, the effort will fail if the design (style guides) are not there – Design process needs to be part of the agile process, with sprint tasks. No long lifecycle or extensive research.

Long Term (Approach) Should we rewrite? – Redoing the app will be hard and risky. A significant amount of time will be spent in understanding very specific behavior of current ACA – No clear benefit by simply porting to another technology. Instead: Reimagine ACA as a new kind of civic portal.

Proposed Next ACA Design for the cloud Find a better balance between customizability and UI/UX control ACA dictates the UI, not a common AA template that gets strip down. But: Source of Data/Permissions/Business Logic is still AA. Civic ID integration Use AA REST (new architecture) If successful, the product becomes a SaaS offering and existing ACA becomes an ACA Enterprise. Both products coexist, for different customers ACA is there if you need total control or customization.

Proposed Next ACA (Main Components) Home Page – Centered around discovery – Customizable via predefined widgets/tiles. The page has hooks to include widgets – An API makes it possible to include custom widgets outside the AA/ACA release cycle The app acts as a host of micro apps. These apps: – Handle in-take forms and display of record details – Handle exposing a presentation screen to be included as a widget/tile in the front page – Have access to an authentication method (isRegistered or hasPermissions) that allows for UI control but permissions live in AA A User dashboard – “My Applications” / Applications Pending / Notifications A common UI framework – UI Framework provides consistent look and feel across apps – It provides a framework for micro apps. For example. A PageFlowController that handles navigation in your forms

Proposed Next ACA (Homepage) Customer can customize Header/Footer Customer can customize the appearance of body by selecting from a predefined set of styles (ex. Directory, set of tiles, and so on), and the content of each container

Proposed Next ACA (Deliverables) What: A prototype that has: – a customizable home page – 1 app that can demonstrate functionality end-to- end (intake forms and display its data) – user dashboard. When: User’s Conference/Summer(?) Needs: Eng/UX resources