Back in the day, when software was released (on physical media), it was considered done. In the present, some products could benefit from a limitation like that. To tie development to something immutable, such as a physical thing or a hard deadline, might just foster a sense of responsibility to design our product so it has what it takes to last a few years.
In the future that’s forever one short year away, brilliantly functional, widely implemented APIs will redeem us from our toil and trouble. We just have to get ready for their coming, while seeing to the nitty-gritty of making the web work in the present. Sadly, it’s a lot less predictable than that. Every new standard has to start small, and we’ll always need to choose which API to back and which to pass over.
Decoupling your CMS can broaden your options for the presentation layer, let team members narrow their focus to what each does best, or provide data for iOS and Android applications along with a responsive site. Maybe the greatest benefit is that having to consider the relationship between the CMS and rendering layer helps break up assumptions about delivery formats, making you more future-friendly along the way. Mark Llobrera shares a couple of tales where headless was the right solution.
Making module syntaxes play well together, managing dependencies, keeping up with third-party code—the devil is in the details when it’s time to ship. You can’t let your focus wander too much while performing these important tasks. Still, though—it’s so boring. Lyza D. Gardner feels your pain.
What drives us to learn? Often, it’s seeing an incredible app or site and wanting to make something like it. Then, the next amazing thing takes us further along our learning journey. If you’re still learning today—and who isn’t—Nishant Kothary is nudging you to check out Swift, Apple’s open-source programming language. You might discover it’s a whole new way to love the web.
The people who pay for enterprise software aren’t the ones who try to work in it day after day. How much has been spent on “Solutions” with an abundance of features that don’t help users get their jobs done? If design can alleviate some of that dysfunction, it doesn’t seem like a mere luxury anymore. Rian van der Merwe shares his four-step approach to redeeming the awkward rich kid no one wants to play with.
For some, Facebook’s Instant Articles is a sign that the traditional web stack is incapable of giving users a first-class reading experience. But the sluggish performance of the web isn’t due to an inherent flaw in the technology. That particular problem originates between the seat and the keyboard, where builders make choices that bloat their sites. For Mark Llobrera, Instant Articles is a sign that we need to prioritize performance like we actually mean it.
The notion of the web as an application platform has never been more popular. Single-page frameworks like Ember and Angular make it easy to create complex applications that offer richer, more robust experiences than traditional websites can. But this benefit comes at a cost. Ross Penman tells us what we can do about it.
The number of predictions that algorithms can make about us from even minimal data is shocking. Although we’re offered privacy settings that let us control who of our friends sees what, all our information and behavior tends to be fair game for behind-the-scenes tracking. We simply don’t know everything that’s being done with our data currently, and what companies might be able—and willing—to do with it in the future. Laura Kalbag believes it’s time to locate the exits.
You’re proud of your product, and welcome user suggestions on making it even better. Will you be able to make everyone happy? Should you even aim to accommodate them all? Before you start coding, think about how to prioritize feature requests, and even say no to some.