“It’s going to be the coolest thing ever.”
You know enough by now to be doubtful when a client makes this statement, but you’re willing to entertain the idea that this may not, in fact, be a tragedy in the making.
“It’s going to be a music machine – like, full keyboard and everything – but each of the keys is going to be mapped to – wait for it – cat sounds! We’ll call it the ‘Meowsic Machine’! Oh, and we need it to be accessible to everyone via the Web. Which is easy, right?
You are reminded that the universe can be a cruel place.
It’s now your job to make this happen. Over the course of a few posts, we’re going to look at the Web Audio API, and build the Meowsic Machine together. In the process, we’ll also enjoy a dalliance with Vue.js, and dip our toes into the deep-end with Web Workers. Today, we take the first step in this historic journey—convincing the browser to actually let us play sounds.
Last time, we got into the nitty-gritty on how to make your web application into a Progressive Web Application (PWA to its friends). I promised we’d dig even deeper this time, and show you how to make your web app a little more ‘native’ on Android – and how to deal with iOS Safari’s special snowflake syndrome.
It’s project kickoff time, and you’re having a conversation with your client about what form the application will take:
Client: I’m thinking mobile app. Our users will definitely be using this on the go.
Dev: Sure, we can do a native mobile-
Client: Mind you, we’ll want a desktop version too. We’ll need to use it from the office.
Dev: Okay, well, a responsive web app-
Client: One of our priorities is definitely ease of access – we’ll need the app accessible from the home screen, ’cause who has time for typing in URLs, amirite? We’ll also want it to be useable offline, whenever people want to.
Dev: Ye-yeah, no problem, we can wrap your web app in a webview, bundle it up as a native app, and-
Client: Yeah, cool. So they’ll just be able to go to the site and install the app, right?
Dev: Well, no, they’ll have to download it from the appropriate App Store.
Client: Eh, that’s a no-go – this is internal only, we can’t have it showing up in the app stores. Didn’t I make that clear from the start?
The term your client was looking for is Progressive Web App – an application that acts like a responsive web app when accessed from the browser on any device, but can be installed to mobile devices like a native application. The link above makes the case for PWAs, so we won’t belabour the point – if you’re still here, it’s because you’re convinced it’s time to build a PWA.
A young developer, new to the Tao of the client-side, comes to a Master of the way, and speaks thusly: “Oh Master, our application nears completion; and lo, cat pics can be drawn upon, and captions fixated thereto, for the creation of humour and the bounteous enjoyment of our users.”
“This is good,” responded the Master.
So, it has come to this.
Reports, yes, your application will have to have reports – in brand colours, with images and logos abounding, and probably festooned with graphs of various sizes, shapes and degrees of relevance to what was once a nice, streamlined set of data. This report has just become a part of the application ‘product’, meant not just to communicate, but also to entice and enthrall. Form has become just as important as function… and, did I forget to mention? It also needs to be exportable.
Exportable, portable, downloadable, shareable – because as I mentioned, it’s not just data now. It is now something clients/users need to be able to ‘have’, to attach to emails, send to their marketing departments, and incorporate into their powerpoints.
There are a few ways to make this happen, but generally speaking, it’s time to break out the PDFs.