A phone addict puts away his phone for a month. I’m not convinced that phones hurt our brains, but this looks like an interesting story.
Favorite quote from this story:
“I’m sad that you’re having trouble with this,” she said, “because it’s been great for me.”
This is Lyft’s approach for adding a major new feature to their app. -> eng.lyft.com/from-four-wheels-to-two-403bcf1cbf59
I heard about this on the iOS Dev Discussions podcast.
Feature flags, feature modules, launching early and iterating small, facing questions they didn’t have answers to until they did some real world experimenting and iterating.
Love this…
Every new feature is a chance to start with a clean slate, and it’s often tempting to immediately build for scale. We all want our products to launch to massive fanfare and usage, but more often than not, the path to success for new features is slow and steady. With steady growth in mind, we designed our first architecture to support exactly what’s needed for our first product iteration, and nothing more
Also…
The computer scientist in me was angry, but when the datasets are small enough, reasonable tradeoffs can be made in the short term without sacrificing the user experience. When choosing the “rewrite” approach, it’s important to be confident that the code will stay simple and easily explainable. In this case, the algorithm wasn’t perfect, but it worked reliably and quickly.
This post describes how we detect and communicate network status as part of making Superhuman the fastest and most reliable email experience in the world. Our previous post described an offline…
— Read on blog.superhuman.com/building-reliable-apps-on-unreliable-networks-3f75743fc457
In this case, they detect online/offline state in a web browser mostly for the purpose of communicating that state to the user so they can tell what is going on.
The web app keeps track of network state. If a network request times out, the state is set to offline. Then it polls every 10 seconds to see when the network comes back online.
This approach seems alright for a webapp, but in a mobile app I think we’d avoid polio every 10 seconds to see if the app is online. Perhaps poll on the next natural network request instead, or trigger on events such as view-will-appear or return-to-foreground.
Nowadays, almost everyone has access to either wireless network or the mobile network. Does it mean that we shouldn’t be concerned with the availability of network when making mobile apps?
— Read on www.netguru.com/blog/how-to-design-offline-first-approach-in-mobile-app
Great overview of building an app that works offline first as a means to a great user experience.
The offline-first approach is not the universal solution to every problem you will experience with unreliable network connectivity – it heavily depends on your app’s requirements. It’s more like a design approach that lets you focus on what really matters to your end user: a robust app with a great user experience.
Mental Break Town 