Tags: ios

57

sparkline

Tuesday, April 10th, 2018

Why Suffolk Libraries chose to build their own self-service app.

It’s so great to see the initial UX work that James and I prototyped in a design sprint come to fruition in the form of a progressive web app!

In the case of this web-app, if the tablets go offline, they will still store all the transactions that are made by customers. Once the tablet comes back online, it will sync it back up to the server. That is, essentially, what a Progressive Web App is — a kind of a website with a few more security and, most importantly, offline features.

Friday, March 9th, 2018

How To Become A Centaur

We hoped for a bicycle for the mind; we got a Lazy Boy recliner for the mind.

Nicky Case on how Douglas Engelbart’s vision for human-computer augmentation has taken a turn from creation to consumption.

When you create a Human+AI team, the hard part isn’t the “AI”. It isn’t even the “Human”.

It’s the “+”.

Thursday, January 25th, 2018

Safari 11.1

Squee! The next time there’s an update for OS X and iOS, Safari will magically have service worker support! Not only that, but Safari on iOS will start using the information in web app manifests for adding to home screen.

That’s an impressive turnaround.

Sunday, January 14th, 2018

TASAT – There’s a Story about That

An initiative by David Brin and the Arthur C. Clarke Center For Human Imagination at UC San Diego. You are confronted with a what-if scenario, and your task is to recall any works of speculative fiction that have covered it.

Accessing more than a hundred years of science fiction thought experiments, TASAT taps into a passionate, global community of writers, scholars, librarians, and fans. We aim to curate a reading list applicable to problems and possibilities of tomorrow.

Thursday, November 2nd, 2017

Building Flexible Design Systems // Speaker Deck

The slides from Yesenia’s talk on scenario-driven design.

Monday, October 9th, 2017

Microsoft Edge for iOS and Android: What developers need to know - Microsoft Edge Dev Blog

This is such a strange announcement from Microsoft. It’s worded as though they chose to use the WebKit engine on iOS. But there is no choice: if you want to put a browser on iOS, you must use the WKWebView control. Apple won’t allow any other rendering engine (that’s why Chrome on iOS is basically a skin for Safari; same for Opera on iOS). It’s a disgraceful monopolistic policy on Apple’s part.

A word to the Microsoft marketing department: please don’t try to polish the turd in the shit sandwich you’ve been handed by Apple.

Saturday, October 7th, 2017

Notifications

I’ve written before about how I use apps on my phone:

If I install an app on my phone, the first thing I do is switch off all notifications. That saves battery life and sanity.

The only time my phone is allowed to ask for my attention is for phone calls, SMS, or FaceTime (all rare occurrences). I initiate every other interaction—Twitter, Instagram, Foursquare, the web. My phone is a tool that I control, not the other way around.

To me, this seems like a perfectly sensible thing to do. I was surprised by how others thought it was radical and extreme.

I’m always shocked when I’m out and about with someone who has their phone set up to notify them of any activity—a mention on Twitter, a comment on Instagram, or worst of all, an email. The thought of receiving a notification upon receipt of an email gives me the shivers. Allowing those kinds of notifications would feel like putting shackles on my time and attention. Instead, I think I’m applying an old-school RSS mindset to app usage: pull rather than push.

Don’t get me wrong: I use apps on my phone all the time: Twitter, Instagram, Swarm (though not email, except in direst emergency). Even without enabling notifications, I still have to fight the urge to fiddle with my phone—to check to see if anything interesting is happening. I’d like to think I’m in control of my phone usage, but I’m not sure that’s entirely true. But I do know that my behaviour would be a lot, lot worse if notifications were enabled.

I was a bit horrified when Apple decided to port this notification model to the desktop. There doesn’t seem to be any way of removing the “notification tray” altogether, but I can at least go into System Preferences and make sure that absolutely nothing is allowed to pop up an alert while I’m trying to accomplish some other task.

It’s the same on iOS—you can control notifications from Settings—but there’s an added layer within the apps themselves. If you have notifications disabled, the apps encourage you to enable them. That’s fine …at first. Being told that I could and should enable notifications is a perfectly reasonable part of the onboarding process. But with some apps I’m told that I should enable notifications Every. Single. Time.

Instagram Swarm

Of the apps I use, Instagram and Swarm are the worst offenders (I don’t have Facebook or Snapchat installed so I don’t know whether they’re as pushy). This behaviour seems to have worsened recently. The needling has been dialed up in recent updates to the apps. It doesn’t matter how often I dismiss the dialogue, it reappears the next time I open the app.

Initially I thought this might be a bug. I’ve submitted bug reports to Instagram and Swarm, but I’m starting to think that they see my bug as their feature.

In the grand scheme of things, it’s not a big deal, but I would appreciate some respect for my deliberate choice. It gets pretty wearying over the long haul. To use a completely inappropriate analogy, it’s like a recovering alcoholic constantly having to rebuff “friends” asking if they’re absolutely sure they don’t want a drink.

I don’t think there’s malice at work here. I think it’s just that I’m an edge-case scenario. They’ve thought about the situation where someone doesn’t have notifications enabled, and they’ve come up with a reasonable solution: encourage that person to enable notifications. After all, who wouldn’t want notifications? That question, if it’s asked at all, is only asked rhetorically.

I’m trying to do the healthy thing here (or at least the healthier thing) in being mindful of my app usage. They sure aren’t making it easy.

The model that web browsers use for notifications seems quite sensible in comparison. If you arrive on a site that asks for permission to send you notifications (without even taking you out to dinner first) then you have three options: allow, block, or dismiss. If you choose “block”, that site will never be able to ask that browser for permission to enable notifications. Ever. (Oh, how I wish I could apply that browser functionality to all those sites asking me to sign up for their newsletter!)

That must seem like the stuff of nightmares for growth-hacking disruptive startups looking to make their graphs go up and to the right, but it’s a wonderful example of truly user-centred design. In that situation, the browser truly feels like a user agent.

Saturday, September 23rd, 2017

Designing Websites for iPhone X | WebKit

This could be a one-word article: don’t.

More specifically, don’t design websites for any specific device. That way lies pain (and it is not the way of the web).

But read on for a textbook example of how not to introduce new CSS properties. Apple proposed the new syntax that they’re shipping. Now it’s getting standardised …with a different name. So basically Apple are shipping the equivalent of a vendor-prefixed property without the vendor prefix.

Thursday, September 21st, 2017

Understanding the WebView Viewport in iOS 11 - Ayogo Health Inc.

One more reason not to use sticky headers on mobile.

Removing the White Bars in Safari on iPhone X

You could add a bunch of proprietary CSS that Apple just pulled out of their ass.

Or you could make sure to set a background colour on your body element.

I recommend the latter. Because reasons.

Sunday, June 25th, 2017

Aspect Ratios in CSS are a Hack | Bram.us

Bram hopes for a way to define aspect ratios natively in CSS. We can sort of manage it now, but all the solutions are pretty hacky.

Wednesday, May 31st, 2017

A Love Letter to CSS

My argument is relatively simple: creating a comprehensive styling mechanism for building complex user interfaces is startlingly hard, and every alternative to CSS is much worse. Like, it’s not even close.

Saturday, October 8th, 2016

Why we are suing Apple for better HTML5 support in iOS?

Finally! Apple are being sued for refusing to allow any non-Webkit browsers to be installed on iOS.

I’m not usually in favour of legal action but in this case, there doesn’t seem to be any other recourse.

We would be delighted at Nexedi to create a Web browser for iOS with better HTML5 support based on a recent version of Blink library for example. But as soon as we would publish it, it would be banned from Apple’s AppStore. Many developers have experienced this situation already. Many companies are being hurt by this situation. Some companies have already begged Apple to improve HTML5 support in iOS with little significant results.

Wednesday, June 29th, 2016

Audacious Fox: Mini Interview: Loren Brichter on the Sale of Letterpress to Solebon

Colin pointed out this interesting perspective from an iOS developer moving to the web:

My work for the last few years has been on the web, and honestly, it’s a breath of fresh air. Instant refreshing, surprisingly good debugging / perf tools, intrinsically multi-platform, and most importantly, open.

Web tech gets a lot of shit from native devs (some of it deserved). But the alternatives are worse. I find the entire concept of App Review morally questionable despite Apple’s good intentions. So I sleep better at night not being part of that anymore. Sure, the web is messy, and it’s delicate, but it’s important and good and getting better fast.

Sunday, June 12th, 2016

Man-Computer Symbiosis

J. C. R. Licklider’s seminal 1960 paper. I’ve added it to this list of reading material.

The title should, of course, read “Person-Computer Symbiosis.”

Tuesday, May 31st, 2016

Progressive Web Apps and our regressive approach | Christian Heilmann

So remember when I was talking about “the ends justify the means” being used for unwise short-term decisions? Here’s a classic example. Chris thinks that Progressive Web Apps should be made mobile-only (at least to start with …something something something the future):

For now, PWAs need to be the solution for the next mobile users.

End users deserve to have an amazing, form-factor specific experience.

I couldn’t disagree more. End users deserve to have an amazing experience no matter the form-factor of their device.

Wednesday, April 6th, 2016

Progressive Web Apps have leapfrogged the native install model … but challenges remain

While many challenges remain, the good news is … it’s progressive. Developers can already see the benefits by sprinkling in these technologies to their existing websites and proceed to build on them as browsers and operating systems increase support.

Monday, January 11th, 2016

Without delay

When I wrote about mobile Safari adding support for touch-action: manipulation, I finished with this snarky observation:

Anyway, I’m off to update my CSS even though this latest fix probably won’t land in mobile Safari until, oh ….probably next October.

Historically, Apple have tied mobile Safari updates to iOS version number increments, and they happen about once a year. But this time, it looks like my snark was unfounded:

On Safari for iOS, the 350 ms wait time to detect a second tap has been removed to create a “fast-tap” response. This is enabled for pages that declare a viewport with either width=device-width or user-scalable=no. Authors can also opt in to fast-tap behavior on specific elements by using the CSS touch-action property, using the manipulation value.

That’s from the release notes for Safari 9.1—a point release.

I’m very pleased to have been absolutely wrong with my prediction of Apple’s timing.

Wednesday, December 16th, 2015

More Responsive Tapping on iOS | WebKit

This solution to the mobile tap delay by the WebKit team sounds like what I was hoping for:

Putting touch-action: manipulation; on a clickable element makes WebKit consider touches that begin on the element only for the purposes of panning and pinching to zoom. This means WebKit does not consider double-tap gestures on the element, so single taps are dispatched immediately.

It would be nice to know whether this has been discussed with other browser makers or if it’s another proprietary addition.

Sunday, November 29th, 2015

Blocked! - O’Reilly Radar

Following on from that Wired article I linked to about disabling JavaScript, Simon St. Laurent brings in another factor—content blockers on iOS:

Apple offers its users the power to turn off much of the Web: fonts, styles, scripts, and more.

He rightly points out that the answer to building a robust, resilient web has been here all along:

Turning off web fonts, CSS, and images will frustrate designers and limit user interface possibilities, but turning off JavaScript might mean that we have to reconsider the architecture of our applications. Without JavaScript, the Web returns to its foundations of HTTP requests returning pages, with links and form submissions as the backbone of application structure.