If you only interact with users when they need support or have a feature request, you’re only interacting with the minority of your customers. The ones who don’t reach out to you may be creating their own workarounds to a problem you’d love to hear about, or they may have a use case that would lead to a brilliant feature. Are you guilty of the same developer shyness? Do you build things to enhance a tool or service for your own use, and assume the developer is too busy to want to hear about it? Don’t wait until there’s a need for support: ask your happy customers what they do with your product, and tell developers how you’re using their product.
As the newest operating systems for Android and iOS enable deep-linking directly into third-party apps, Anthony Colangelo sees an expanding definition of “the web” and an opportunity to better serve our users.
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.