Repainting the Plane... at 30,000 Feet
•Download as PPTX, PDF•
1 like•370 views
Presented at the Boulder Ruby Groups's Boulder Startup Week meeting: http://www.meetup.com/boulder_ruby_group/events/221392650/
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Repainting the Plane... at 30,000 Feet
Similar to Repainting the Plane... at 30,000 Feet (20)
More from Recurly
More from Recurly (6)
Recently uploaded
Recently uploaded (20)
Repainting the Plane... at 30,000 Feet
- 1. Repainting the Plane… at 30,000 Feet Andrew Morton Senior Engineer, Recurly @drewish Andy Montgomery Head of Design, Recurly @mntgmry
- 2. 2 Background
- 3. 3 Provide a significant visual overhaul. Don’t disrupt customer workflows.
- 4. 4 But… People Don’t Like Change
- 6. 6 The Elements of User Experience Visual Design Interface Design Interaction Design Information Architecture
- 7. 7 Visual System and Style Guide
- 8. + JSON API
- 9. 9 Front-end team started running into “issues” PROBLEMS • Many edge cases to consider • Duplicating a lot of Ruby logic in JavaScript • JS folks didn’t fully understand all the Rails app’s functionality • A *lot* of pages to move into an Angular app
- 10. 10 API team also started running into “issues” PROBLEMS • Wanted to build a production grade API • Needed to build 90+ API controllers
- 13. Factors in Decision 13 CHANGING COURSE We wanted to: • Stay with Rails • Develop new UI in parallel • Use the HTML components • Keep webpack as our build system
- 14. 14 Rails Engine
- 15. What’s a Rails Engine? 15 RAILS ENGINE “Rails::Engine allows you to wrap a specific Rails application or subset of functionality and share it with other applications or within a larger packaged application…”
- 16. Benefits 16 RAILS ENGINE • Allowed a parallel set of views, styles and JS — only added to the view path when user toggles a session variable • Allowed use of webpack — assets are statically compiled in the gem • Decoupled the UI changes from the API work
- 17. 17
- 18. Drawbacks 18 RAILS ENGINE • Created an implicit interface across two projects • Was hard to test in isolation — thankfully our QA team likes Selenium tests
- 19. Summary 19 RAILS ENGINE • Worked well, but not a long term solution • Planning to deprecate the engine and move contents to app
- 20. Next Steps 20 FUTURE WORK • Improve site navigation and structure • More creative/intuitive interaction design (minimize clicks) • Focus more on React components than AngularJS apps
Editor's Notes
- Recurly is a 5 year old subscription billing company. We use rails heavily (as well as Node and Java). We have a Rails app that our merchants use to manage their customers and subscriptions This is the story of how we updated the app design without “landing the plane”
- How this all started? design team’s frustration with the existing, outdated UI limitations we felt in making improvements for the customer experience creative interaction solutions (We were living an iTunes circa 2002 world.) different eras of design and styling across the app. Different approaches a full redesign of the product from the ground up page by page updates to particularly bad pages, etc. But as we thought about it more, we settled on a core principle for the project.
- The design update should provide a significant visual overhaul without disrupting our merchant’s workflows. (Reflect back on how this principle applies to the various approaches and their feasibility. )
- But, people still don’t like change! However we also knew that change was necessary in order to achieve the larger improvements our customers wanted and the design quality the average consumer (and business person) has become accustomed to. For that reason we determined for this redesign that we would strive to make as few changes to the functionality and existing workflows as possible. Changing one thing on your customers is hard enough but we knew combining a new look with new workflows would be significantly disruptive.
- design resourcing standpoint team would be small and the timeline compressed for completing this project. Making changes to both the look and the functionality would require more time for research and testing, if not a larger team.
- Let’s talk about this in terms of the Jesse James Garrett’s “Elements of User Experience” Diagram — However, long-term, we knew that getting this new visual UI system in place would enable us to make larger IA and interaction design changes in the future. Incremental approach enable us to update the product visually as well as create a more sustainable codebase. As customers adjust to the new look, it paves the way for larger functional changes in the future. Taking a systematic approach today would pay dividends in the future.
- This framework (visual refresh without changes to the layout or workflows) helped to speed the design process immensely. didn’t have to make decisions about where elements would go on the page or how they would interact with each other. freed us up to focus primarily on aesthetics and usability, creating a visual system and style guide that would work for all the existing views in the product. Very systematic approach cataloging all of the various design elements in the current app and compiling them into consistent components and design patterns. The goal was to take a very disorganized collection of UI elements and turn it into a predictable design system with HTML components. Eventually this would allow developers to follow patterns rather than relying on one off designs for each page.
- At the same time, the engineering team determined this would be a good time to move the UI from a Rails to a single-page app using the Angular.js framework. It would be supported by a new JSON API. The engineering team began the process of stubbing out API endpoints and generating the front-end code to support a new design. Excited to have it driving API work, would need a full API to support it and at the end you’d end up with a full function API… If your spidey sense is telling this sounds like trouble…
- All of our functionality isn’t always apparent. Merchants can enable things like support for multiple currencies, VAT and sales tax. That expands the number of permutations that need designs, programming and testing. Duplicated a lot of helpers and logic that had crept into the views The front-end team was new to Recurly and didn’t have a ton of experience with app or fully understand how much there was to convert. One described it as an iceberg where much of the functionality is hidden from view.
- Everyone was excited about building out a new “v3” API and there were lots of *little* things to fix - improve the naming on some entities and attributes - improve error handling There were 90 something controllers, that just a huge amount of functionality to build out and write tests for. Side note: We wanted the API controllers separate from the UI controllers because we’d been burned back on v1. It was hard to improve the UI and preserve API compatibility, so the UI functionality was moved into its own controller.
- As the person responsible for customer’s good experience with our product, I started to get really concerned. The single-page app, while allowing for some nice interactions (infinitely scrolling tables, etc.) was also introducing a variety of new variables: a traditional web form approach is two different screens, View and Edit. single-page app, it was actually easier to make it a single screen, with two different states, Viewing and Editing. slick interactions, it also meant we needed to spend a great deal more time thinking through how this would change the UI and what those interactions would look like in each state. Had we been merely reskinning the old pages, all the logic and screens would be predictable and only the visual layer updated. engineering approach, with the new API, effectively meant that all of the existing app logic had to be recreated from scratch. All of the edge-cases and various scenarios we’d solved for over the years were being rediscovered all over again.
- Based on these concerns we pulled the team together to figure out how we could get the project back on track to deliver on the initial promise. discussions and some research, we decided to radically simplify the scope. We already had a design system created and built out HTML components and the style guide that we really wanted to continue to us.
- Parallel allowed us to jump back and forth between new and old, if there was a bug, customers would be able to work around it Had a build a UI library of components for the Angular app. Would be great if we could avoid moving over to Rails asset pipeline and continue using webpack for CSS preprocessing and JS minification/bundling
- Here’s where I admit that I’m not a rails expert. Rails engines are a relatively old concept in the community but it was totally new to me. There were a few blog posts that were very helpful in realizing the potential of the rails engine: http://www.shopify.com/technology/15646068-rebuilding-the-shopify-admin-improving-developer-productivity-by-deleting-28-000-lines-of-javascript http://tech.taskrabbit.com/blog/2014/02/11/rails-4-engines/
- We don’t have time to go into the details of rails engines, but conceptually you can think of it as a rails app that can be embedded in another app. I really just wanted to make people aware of them because the give you a pretty powerful tool for organizing and sharing code between rails apps. While doing some research for this talk I discovered our pivotal labs hosts did several great posts on how they used rails engines: http://pivotallabs.com/migrating-from-a-single-rails-app-to-a-suite-of-rails-engines/ We used the engine in a very simple way to just package up the new views, styling, and JS code.
- Allowed us to create new views that could live alongside existing views minimizing disruption Also included logic to gate access to the new UI, first to our employees, then beta testers, then all merchants We’re still using webpack for bundling and minification. JS and CSS are statically compiled in the engine’s asset folder
- Adding new features requires changes to both projects. There’s a risk that someone making changes to the main app won’t realize that the engine is impacted.
- Using the engine was a success for the migration but it’s not a long term solution.
- Andy Improve site navigation and structure (reference Elements of UX) More creative/intuitive interaction design (minimize clicks) Andrew Avoid big bangs. React components let us consume the same API but we can do specific pages in the app where we get the most bang for the buck
- We’re starting up an office in Boulder and looking for senior rails devs. There’s a few of us here in the green Recurly shirts so if you’re interested come up and talk to us after this.