Jake Archibald: Building SVGO's Missing GUI =========================================== By Paul Robert Lloyd Monday, 23 March 2015 Having spent many hours simplifying, optimising and minifying SVGs, typically using a combination of tools and services, I was overjoyed to learn that [Jake Archibald][1] had [taken it upon himself][2] to build a web-based GUI atop [SVGO][3]. [SVGOMG][4] is easy to use and surfaces the range of optimisation options offered by SVGO. But beyond the obvious utility, it stands out as an example of how to build a 'web app' ([whatever that means][5]) in a responsible and accessible way. I asked Jake a few questions about how he went about designing and developing this application. ### SVGOMG has a truly native app feel. What obstacles did you overcome (if any) to make it work so seamlessly on the web? > It was easier than I expected, but I think I was expecting it to be impossible. I was surprised at how much I used [flexbox][6], and how stable it is across modern browsers. Pretty much all of the layout is flexbox driven. > > All the heavy lifting, such as SVG parsing and minification, happens in [web workers][7], so the UI stays responsive. But the rule for runtime performance is still "if you paint, you lose", so I had to spend time ensuring everything that moved had its own GPU layer and used simple transforms. There's one downside to this, if you zoom the SVG preview in Chrome/Safari you start to see pixels. Still looking for a way to fix this that doesn't kill performance. > > I developed entirely in Chrome (disclaimer: I work at Google), then bug fixed in other browsers afterwards. Firefox pretty much worked straight away, in fact the issues were mostly down to stricter spec compliance. IE was okay, the bugs were mainly in newer and lesser used features such as [blob URLs][8]. The biggest disappointment was Safari. > > I was shocked how much hacking Safari needed to get basic features working. Smooth scrolling within an element still needs a custom property, which will simply stop working when combined with other properties like CSS animations. Every tap in iOS Safari comes with a 300ms delay. You can work around this with [Fastclick][9], but even the authors admit it's a hack. I also found that features like [IndexedDB][10] disappear if the site is launched from a home screen icon. I hope Apple step up their game here! ### One of the most pleasing features of the app is how it adapts to different screen sizes. Did you make any adaptions to your initial design/concept to achieve this? > I'm terrible at design. I don't know what I'm doing. I really don't. [Google's] [Material Design][11] helped me a lot by telling me what to do. In the cases where Material Design didn't have rules, I spent a long time sketching and throwing stuff out. > > Unlike a lot of apps, the settings need to be visible alongside the output. It's kinda tough to fit it all in on mobile, but I decided to split the output almost 50/50. The settings go at the bottom of the screen so you don't cover the output with your hand while interacting. ### What progressive enhancement techniques and approaches did you use to ensure the widest possible usage for the app? > In terms of features, there are a couple of polyfills that are brought in dynamically for the browsers that need them. IE needs a [Promise polyfill][12], Safari needs Fastclick. > > I stuck to enhancing existing browser features rather than reinventing anything. The switches are all checkboxes underneath, styled using `