text:
Journal tags: apps
I was chatting with my new colleague Alex yesterday about a link she had shared in Slack. It was the Nielsen Norman Group's annual State of Mobile User Experience report.
There's nothing too surprising in there, other than the mention of Apple's app clips and Google's instant apps.
Perhaps I lead a sheltered existence, but as an iPhone user, I don't think I've come across a single app clip in the wild.
I remember when they were announced. I was quite worried about them.
See, the one thing that the web can (theoretically) offer that native can't is instant access to a resource. Go to this URL—that's it. Whereas for a native app, the flow is: go to this app store, find the app, download the app.
(I say that the benefit is theoretical because the website found at the URL should download quickly—the reality is that the bloat of "modern" web development imperils that advantage.)
App clips—and instant apps—looked like a way to route around the convoluted install process of native apps. That's why I was nervous when they were announced. They sounded like a threat to the web.
In reality, the potential was never fulfilled (if my own experience is anything to go by). I wonder why people didn't jump on app clips and instant apps?
Perhaps it's because what they promise isn't desirable from a business perspective: "here's a way for users to accomplish their tasks without downloading your app." Even though app clips can in theory be a stepping stone to installing the full app, from a user's perspective, their appeal is the exact opposite.
Or maybe they're just too confusing to understand. I think there's an another technology that suffers from the same problem: progressive web apps.
Hear me out. Progressive web apps are—if done well—absolutely amazing. You get all of the benefits of native apps in terms of UX—they even work offline!—but you retain the web's frictionless access model: go to a URL; that's it.
So what are they? Are they websites? Yes, sorta. Are they apps? Yes, sorta.
That's confusing, right? I can see how app clips and instant apps sound equally confusing: "you can use them straight away, like going to a web page, but they're not web pages; they're little bits of apps."
I'm mostly glad that app clips never took off. But I'm sad that progressive web apps haven't taken off more. I suspect that their fates are intertwined. Neither suffer from technical limitations. The problem they both face is inertia:
The technologies are the easy bit. Getting people to re-evaluate their opinions about technologies? That's the hard part.
True of progressive web apps. Equally true of app clips.
But when I was chatting to Alex, she made me look at app clips in a different way. She described a situation where somebody might need to interact with some kind of NFC beacon from their phone. Web NFC isn't supported in many browsers yet, so you can't rely on that. But you don't want to make people download a native app just to have a quick interaction. In theory, an app clip—or instant app—could do the job.
In that situation, app clips aren't a danger to the web—they're polyfills for hardware APIs that the web doesn't yet support!
I love having my perspective shifted like that.
The specific situations that Alex and I were discussing were in the context of museums. Musuems offer such interesting opportunities for the physical and the digital to intersect.
Remember the pen from Cooper Hewitt? Aaron spoke about it at dConstruct 2014—a terrific presentation that's well worth revisiting and absorbing.
The other dConstruct talk that's very relevant to this liminal space between the web and native apps is the 2012 talk from Scott Jenson. I always thought the physical web initiative had a lot of promise, but it may have been ahead of its time.
I loved the thinking behind the physical web beacons. They were deliberately dumb, much like the internet itself. All they did was broadcast a URL. That's it. All the smarts were to be found at the URL itself. That meant a service could get smarter over time. It's a lot easier to update a website than swap out a piece of hardware.
But any kind of technology that uses Bluetooth, NFC, or other wireless technology has to get over the discovery problem. They're invisible technologies, so by default, people don't know they're even there. But if you make them too discoverable— intrusively announcing themselves like one of the commercials in Minority Report —then they're indistinguishable from spam. There's a sweet spot of discoverability right in the middle that's hard to get right.
Over the past couple of years—accelerated by the physical distancing necessitated by The Situation—QR codes stepped up to the plate.
They still suffer from some discoverability issues. They're not human-readable, so you can't be entirely sure that the URL you're going to go to isn't going to be a Rick Astley video. But they are visible, which gives them an advantage over hidden wireless technologies.
They're cheaper too. Printing a QR code sticker costs less than getting a plastic beacon shipped from China.
QR codes turned out to be just good enough to bridge the gap between the physical and digital for those one-off interactions like dining outdoors during a pandemic:
I can see why they chose the web over a native app. Online ordering is the only way to place your order at this place. Telling people "You have to go to this website" …that seems reasonable. But telling people "You have to download this app" …that's too much friction.
Ironically, the nail in the coffin for app clips and instant apps might've been hammered in by Apple and Google when they built QR-code recognition into their camera software.
Tuesday, January 24th, 2023 5:30pm
Tagged with native apps mobile technology appclips instantapps pwas progressive webapps hardware physical digital museums qrcodes wireless beacons
Also on Medium
Negativity bias
When I wrote about my hopes and fears for the View Transitions API, a few people latched on to this sentiment:
If the View Transitions API only works for single page apps, it could be the single worst thing to happen to the web in years.
But I also wrote:
If the View Transitions API works across page navigations, it could be the single best thing to happen to the web in years.
I think it's worth focusing on that.
Part of the problem is that I gave my hopes and fears an equal airing. But they're not equally likely.
Take the possibility that the View Transitions API only ships for single page apps, but never ships for regular page transitions. The consequences of that would be big—the API would act as an incentive to build single page apps. But the likelihood of that happening is small. In fact, according to Jake, there's already an implemention for page transitions in the works at Chrome.
Now what if the View Transitions API ships for pages? The consequences would be equally big—the API would act as an incentive to ditch single page apps and build in a more performant, resilient way. Best of all, the chances of that happening are very large indeed (pretty much a certainty now, given Jake's update).
So I made a comparison between both of the consequences, which are equally large, but I didn't make a corresponding comparison of the likelihoods, which are not equally large. Mea culpa!
I should've made it clearer that, although the consequences would be really bad if the View Transitions API only supports single page apps, the actual likelihood of that is pretty slim.
That's probably my negativity bias showing through. (The reason I have a negativity bias is because I am a human. Like, have you ever noticed that if you get feedback on something and 98% of it is positive, you inevitably fixate on the 2%?)
Anyway, the real takeaway here is that if the View Transitions API ships for pages, then the consequences will be really, really good! It would be another nail in the coffin for monolithic JavaScript frameworks slowing down the web. And best of all, the likelihood of this happening is very high!
So let me amend my closing sentences from my previous post:
If the View Transitions API only works for single page apps—which is very unlikely—it could be the single worst thing to happen to the web in years.
If the View Transitions API works across page navigations—which is very, very likely—it could be the single best thing to happen to the web in years.
The glass is half full and it's only going to get fuller. Time to start planning for a turbo-charged web now.
If you've got a website with full page navigations, start thinking about how you'll be able to apply the View Transitions API as a progressive enhancement to improve the user experience.
If you've got a single page app, start thinking about how to ditch a whole bunch of uneccessary dependencies to make a more lightweight foundation of HTML instead of JavaScript, and still get all those slick transitions you get in a single page app!
Tagged with view transitions api singlepageapps spas mpas standards browsers frontend development
Time for transitions
I am simultaneously very excited and very nervous about the View Transitions API.
You may know it by its former name—Shared Element Transitions. The name change is very recent.
I've been saying for years that some kind of API like this would be brilliant:
I honestly think if browsers implemented this, 80% of client-rendered Single Page Apps could be done as regular good ol'-fashioned websites.
Miriam Suzanne describes the theory of View Transitions succinctly:
Shared-element transitions are designed to work with standard web navigation across multiple page loads, as well as page transitions in 'single-page' apps (often called SPAs).
This all sounds brilliant. But the devil is in the implementation details. Right now, the API only works for single page apps. This is totally understandable. For purely pragmatic reasons, single page apps are a simple use case to solve for. It's going to take a lot more work to get this API to work for multi-page apps (or as we used to call them, websites).
If we get a View Transitions API that works across page navigations, it could potentially turbo-charge the web. It will act as a disencentive to building single page apps—you'd be able to provide swish transitions without sacrificing performance or resilience at the alter of a heavy-handed JavaScript-only architecture.
But if the API only ever works for single page apps (which is the current situation), then it will act as an incentive to make any kind of website into a single page app, regardless of whether it's actually the appropriate architecture.
That prospect has me very worried indeed.
I'm making my feelings on this known just in case any of the implementators out there are thinking, "Hey, maybe it's fine that this API only works for single page apps—I'm sure most people would be happy with that."
Update: Jake says:
We're currently landing code in Chrome for the MPA version.
Very happy to hear that! It's already in the spec, but it's good to hear that the implementation isn't going to lag too much.
Also, read this follow-up.
Web notifications on iOS
I've mentioned before that I don't enable notifications on my phone. Text messages are the only exception. I don't want to get notified if a new email arrives (I avoid email on my phone completely) and I certainly don't want some social media app telling me somebody liked or faved something.
But the number one feature I'd like to see in Safari on iOS is web notifications.
It's not for me personally, see. It's because it's the number one reason why people are choosing not to go all in progressive web apps.
Safari on iOS is the last holdout. But that equates to enough marketshare that many companies feel they can't treat notifications as a progressive enhancement. While I may not agree with that decision myself, I get it.
When I'm evangelising the benefits of building on the open web instead of making separate iOS and Android apps, I inevitably get asked about notifications. As long as mobile Safari doesn't support them—even though desktop Safari does—I'm somewhat stumped. There's no polyfill for this feature other than building an entire native app, which is a bit extreme as polyfills go.
And of course, unlike on your Mac, you don't have the option of using a different browser on your iPhone. As long as mobile Safari doesn't support web notifications, nothing on iOS can support web notifications.
I've got progressive web apps on the home screen of my phone that match their native equivalents feature-for-feature. Twitter. Instagram. They're really good. In some ways they're superior to the native apps; the Twitter website is much calmer, and the Instagram website has no advertising. But if I wanted to get notifications from any of those sites, I'd have to keep the native apps installed just for that one feature.
So in the spirit of complaining about web browsers in a productive way, I just want to throw this plea out there: Apple, please support web notifications in mobile Safari!
The good news is that web notifications on iOS might be on their way. Huzzah!
Alas, we're reliant on Maximiliano's detective work to even get a glimpse of a future feature like this. Apple has no public roadmap for Safari. There's this status page on the Webkit blog but it's incomplete—web notifications don't appear at all. In any case, WebKit and Safari aren't the same thing. The only way of knowing if a feature might be implemented in Safari is if it shows up in Safari Technology Preview, at which point it's already pretty far along.
So while my number one feature request for mobile Safari is web notifications, a close second would be a public roadmap.
It only seems fair. If Apple devrels are asking us developers what features we'd like to see implemented—as they should!—then shouldn't those same developers also be treated with enough respect to share a roadmap with them? There's not much point in us asking for features if, unbeknownst to us, that feature is already being worked on.
But, like I said, my number one request remains: web notifications on iOS …please!
Monday, March 7th, 2022 5:56pm
Tagged with apple browser ios mobile safari webkit push notifications progressive webapps frontend development pwas features requests roadmaps
A bug with progressive web apps on iOS
Dave recently wrote some good advice about what to do—and what not to do—when it comes to complaining about web browsers. I wrote something on this topic a little while back:
If there's something about a web browser that you're not happy with (or, indeed, if there's something you're really happy with), take the time to write it down and publish it
To summarise Dave's advice, avoid conspiracy theories and snark; stick to specifics instead.
It's very good advice that I should heed (especially the bit about avoiding snark). In that spirit, I'd like to document what I think is a bug on iOS.
I don't need to name the specific browser, because there is basically only one browser allowed on iOS. That's not snark; that's a statement of fact.
This bug involves navigating from a progressive web app that has been installed on your home screen to an external web view.
To illustrate the bug, I'll use the example of The Session. If you want to recreate the bug, you'll need to have an account on The Session. Let me know if you want to set up a temporary account—I can take care of deleting it afterwards.
Navigate to thesession.org in Safari on an iOS device.
Add the site to your home screen.
Open the installed site from your home screen—it will launch in standalone mode.
Log in with your username and password.
Using the site menu, navigate to the links section of the site.
Click on any external link.
After the external link opens in a web view, tap on "Done" to close the web view.
Expected behaviour: you are returned to the page you were on with no change of state.
Actual behaviour: you are returned to the page you were on but you are logged out.
So the act of visiting an external link in a web view while in a progressive web app in standalone mode seems to cause a loss of cookie-based authentication.
This isn't permanent. Clicking on any internal link restores the logged-in state.
It is surprising though. My mental model for opening an external link in a web view is that it sits "above" the progressive web app, which remains in stasis "behind" it. But the page must actually be reloading, either when the web view is opened or when the web view is closed. And that reload is behaving like a fetch event without credentials.
Anyway, that's my bug report. It may already be listed somewhere on the WebKit Bugzilla but I lack the deductive skills to find it. I'm not even sure if that's the right place for this kind of bug. It might be specific to the operating system rather than the rendering engine.
This isn't a high priority bug, but it is one of those cumulatively annoying software paper cuts.
Sunday, March 6th, 2022 4:15pm
Tagged with ios safari apple mobile browsers bugs webkit progressive web apps pwas webviews authentication state thesession links
I wrote about how I created a page on The Session with instructions for installing the site to your home screen. When I said that I included screenshots on that page, I may have underplayed the effort involved. It was real faff.
I've got an iPhone so generating screenshots (and video) from that wasn't too bad. But I don't have access to an Android phone. I found myself scouring the web for templates that I could use to mockup a screenshot of the address bar.
That got me thinking…
Wouldn't it be cool if there were a service that generated those screenshots for you? You give it a URL, and it spits out screenshots of the site complete with overlays showing the installation flow on Android and iOS. It could even generate the img markup, complete with differently-scaled images for the srcset attribute.
Download the images. Copy that markup. Paste it into a page on your site. Boom! Now you've got somewhere to point your visitors to if you'd like them to install your progressive web app.
There are already some services out there for generating screenshots of mobile phones but they're missing is the menu overlays for adding to home screen.
The devrels at both Google and Microsoft have been doing a great job of promoting progressive web apps. They've built tools to help you with tasks like generating icons or creating your web app manifest. It would be sooooo nifty if those tools also generated instructional screenshots for adding to home screen!
Thursday, January 20th, 2022 3:22pm
Tagged with progressive webapps pwas screenshots mobile android ios installation generator frontend development
Installing progressive web apps
I don't know about you, but it seems like everyone I follow on Twitter is playing Wordle. Although I don't play the game myself, I think it's pretty great.
Not only does Wordle have a very sweet backstory, but it's also unashamedly on the web. If you want to play, you go to the URL powerlanguage.co.uk/wordle. That's it. No need to download an app.
That hasn't stopped some nefarious developers trying to trick people into downloading their clones of Wordle from app stores. App stores, which are meant to be curated and safe, are in fact filled with dodgy knock-offs and scams. Contrary to popular belief, the web is quite literally a safer bet.
Wordle has a web app manifest, which means you can add it to your home screen and it will behave just like a native app (although I don't believe it has offline support). That's great, but the process of adding a web app to your home screen on iOS is ludicrously long-winded.
Macworld published an article detailing how to get the real Wordle app on your iPhone or iPad. On the one hand it's great to see this knowledge being spread. On the other hand it's dispiriting that it's even necessary to tell people that they can do this, like it's a hidden nerdy secret just for power users.
At this point I've pretty much given up on Apple ever doing anything about this pathetic situation. So what can I do instead?
Well, taking my cue from that Macworld article, the least I can do is inform people how they can add a progressive web app to their home screen.
That's what I've done on thesession.org. I've published a page on how to install The Session to your home screen.
On both Android and iPhone the journey to installing a progressive web app begins with incomprehensible iconography. On Android you must first tap on the unlabeled kebab icon—three vertical dots. On iOS you must first tap on the unlabeled share icon—a square with an arrow coming out of it.
When it comes to mobile operating systems, consumer choice means you choose which kind of mystery meat to eat.
I've included screenshots to help people identify these mysterious portals. For iOS I've also included a video to illustrate the quest to find the secret menu item buried beneath the share icon.
I've linked to the page with the installation instructions from the site's "help" page and the home page.
Handy tip: when you're adding a start_url value to your web app manifest, it's common to include a query string like this:
start_url: "/?homescreen"
I'm guessing most people to that so they can get analytics on how many people are starting from an icon tap. I don't do analytics on The Session but I'm still using that query string in my start_url. On the home page of the site, I check for the existence of the query string. If it exists, I don't show the link to the installation page. So once someone has installed the site to their home screen, they shouldn't see that message when they launch The Session.
If you've got a progressive web app, it might be worth making a page with installation instructions rather than relying on browsers to proactively inform your site's visitors. You'd still need to figure out the right time and place to point people to that page, but at least the design challenge would be in your hands.
Should you decide to take a leaf out of the Android and iOS playbooks and use mystery meat navigation to link to such a page, there's an emoji you could potentially use: 📲
It's still worse than using actual words, but it might be better than some random combination of dots, squares and arrows.
(I'm not really serious about using that emoji, but if you do, be sure to use a sensible aria-label value on the enclosing a element.)
Tuesday, January 18th, 2022 12:12pm
Tagged with thesession pwas progressive web apps installation mobile android ios flow icons iconography frontend development homescreen
Media queries with display-mode
It's said that the best way to learn about something is to teach it. I certainly found that to be true when I was writing the web.dev course on responsive design.
I felt fairly confident about some of the topics, but I felt somewhat out of my depth when it came to some of the newer modern additions to browsers. The last few modules in particular were unexplored areas for me, with topics like screen configurations and media features. I learned a lot about those topics by writing about them.
Best of all, I got to put my new-found knowledge to use! Here's how…
The Session is a progressive web app. If you add it to the home screen of your mobile device, then when you launch the site by tapping on its icon, it behaves just like a native app.
In the web app manifest file for The Session, the display-mode property is set to "standalone." That means it will launch without any browser chrome: no address bar and no back button. It's up to me to provide the functionality that the browser usually takes care of.
So I added a back button in the navigation interface. It only appears on small screens.
Do you see the assumption I made?
I figured that the back button was most necessary in the situation where the site had been added to the home screen. That only happens on mobile devices, right?
Nope. If you're using Chrome or Edge on a desktop device, you will be actively encourged to "install" The Session. If you do that, then just as on mobile, the site will behave like a standalone native app and launch without any browser chrome.
So desktop users who install the progressive web app don't get any back button (because in my CSS I declare that the back button in the interface should only appear on small screens).
I was alerted to this issue on The Session:
It downloaded for me but there's a bug, Jeremy - there doesn't seem to be a way to go back.
Luckily, this happened as I was writing the module on media features. I knew exactly how to solve this problem because now I knew about the existence of the display-mode media feature. It allows you to write media queries that match the possible values of display-mode in a web app manifest:
.goback {
@media (display-mode: standalone) {
Now the back button shows up if you "install" The Session, regardless of whether that's on mobile or desktop.
Previously I made the mistake of inferring whether or not to show the back button based on screen size. But the display-mode media feature allowed me to test the actual condition I cared about: is this user navigating in standalone mode?
If I hadn't been writing about media features, I don't think I would've been able to solve the problem. It's a really good feeling when you've just learned something new, and then you immediately find exactly the right use case for it!
Wednesday, January 12th, 2022 4:35pm
Tagged with css mediaqueries mediafeatures thesession displaymode standalone pwas progressive webapps backbutton navigation mobile desktop manifest frontend development writing learning responsive design
Safari 15
If you download Safari Technology Preview you can test drive features that are on their way in Safari 15. One of those features, announced at Apple's World Wide Developer Conference, is coloured browser chrome via support for the meta value of "theme-color." Chrome on Android has supported this for a while but I believe Safari is the first desktop browser to add support. They've also added support for the media attribute on that meta element to handle "prefers-color-scheme."
This is all very welcome, although it does remind me a bit of when Internet Explorer came out with the ability to make coloured scrollbars. I mean, they're nice features'n'all, but maybe not the most pressing? Safari is still refusing to acknowledge progressive web apps.
That's not quite true. In her WWDC video Jen demonstrates how you can add a progressive web app like Resilient Web Design to your home screen. I'm chuffed that my little web book made an appearance, but when you see how you add a site to your home screen in iOS, it's somewhat depressing.
The steps to add a website to your home screen are:
Tap the "share" icon. It's not labelled "share." It's a square with an arrow coming out of the top of it.
A drawer pops up. The option to "add to home screen" is nowhere to be seen. You have to pull the drawer up further to see the hidden options.
Now you must find "add to home screen" in the list
Add to Reading List
Find on Page
It reminds of this exchange in The Hitchhiker's Guide To The Galaxy :
"You hadn't exactly gone out of your way to call attention to them had you? I mean like actually telling anyone or anything."
"But the plans were on display…"
"On display? I eventually had to go down to the cellar to find them."
"That's the display department."
"With a torch."
"Ah, well the lights had probably gone."
"So had the stairs."
"But look you found the notice didn't you?"
"Yes," said Arthur, "yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of The Leopard.'"
Safari's current "support" for adding progressive web apps to the home screen feels like the minimum possible …just enough to use it as a legal argument if you happen to be litigated against for having a monopoly on app distribution. "Hey, you can always make a web app!" It's true in theory. In practice it's …suboptimal, to put it mildly.
Still, those coloured tab bars are very nice.
It's a little bit weird that this stylistic information is handled by HTML rather than CSS. It's similar to the meta viewport value in that sense. I always that the plan was to migrate that to CSS at some point, but here we are a decade later and it's still very much part of our boilerplate markup.
Some people have remarked that the coloured browser chrome can make the URL bar look like part of the site so people might expect it to operate like a site-specific search.
I also wonder if it might blur "the line of death"; that point in the UI where the browser chrome ends and the website begins. Does the unified colour make it easier to spoof browser UI?
Probably not. You can already kind of spoof browser UI by using the right shade of grey. Although the removal any kind of actual line in Safari does give me pause for thought.
I tend not to think of security implications like this by default. My first thought tends to be more about how I can use the feature. It's only after a while that I think about how bad actors might abuse the same feature. I should probably try to narrow the gap between those thoughts.
Tuesday, June 29th, 2021 3:01pm
Tagged with apple safari ios pwas themecolor homescreen browsers standards theming standalone apple metadata progressive webapps security
The principle of most availability
I've been thinking some more about the technical experience of booking a vaccination apointment and how much joy it brought me.
I've written before about how I've got a blind spot for the web so it's no surprise that I was praising the use of a well marked-up form, styled clearly, and unencumbered by unnecessary JavaScript. But other technologies were in play too: Short Message Service (SMS) and email.
All of those technologies are platform-agnostic.
No matter what operating system I'm using, or what email software I've chosen, email works. It gets more complicated when you introduce HTML email. My response to that is the same as the old joke; you know the one: "Doctor, it hurts when I do this." ("Well, don't do that.")
No matter what operating system my phone is using, SMS works. It gets more complicated when you introduce read receipts, memoji, or other additions. See my response to HTML email.
Then there's the web. No matter what operating system I'm using on a device that could be a phone or a tablet or a laptop or desktop tower, and no matter what browser I've chosen to use, the World Wide Web works.
I originally said:
It feels like the principle of least power in action.
But another way of rephrasing "least power" is "most availability." Technologies that are old, simple, and boring tend to be more widely available.
I remember when software used to come packaged in boxes and displayed on shelves. The packaging always had a list on the side. It looked like the nutritional information on a food product, but this was a list of "system requirements": operating system, graphics card, sound card, CPU. I never liked the idea of system requirements. It felt so …exclusionary. And for me, the promise of technology was liberation and freedom to act on my own terms.
Hence my soft spot for the boring and basic technologies like email, SMS, and yes, web pages. The difference with web pages is that you can choose to layer added extras on top. As long as the fundamental functionality is using universally-supported technology, you're free to enhance with all the latest CSS and JavaScript. If any of it fails, that's okay: it falls back to a nice solid base.
Alas, many developers don't build with this mindset. I mean, I understand why: it means thinking about users with the most boring, least powerful technology. It's simpler and more exciting to assume that everyone's got a shared baseline of newer technology. But by doing that, you're missing out on one of the web's superpowers: that something served up at the same URL with the same underlying code can simultaneously serve people with older technology and also provide a whizz-bang experience to people with the latest and greatest technology.
Anyway, I've been thinking about the kind of communication technologies that are as universal as email, SMS, and the web.
QR codes are kind of heading in that direction, although I still have qualms because of their proprietary history. But there's something nice and lo-fi about them. They're like print stylesheets in reverse (and I love print stylesheets). A funky little bridge between the physical and the digital. I just wish they weren't so opaque: you never know if scanning that QR code will actually take you to the promised resource, or if you're about to rickroll yourself.
Telephone numbers kind of fall into the same category as SMS, but with the added option of voice. I've always found the prospect of doing something with, say, Twilio's API more interesting than building something inside a walled garden like Facebook Messenger or Alexa.
I know very little about chat apps or voice apps, but I don't think there's a cross-platform format that works with different products, right? I imagine it's like the situation with native apps which require a different codebase for each app store and operating system. And so there's a constant stream of technologies that try to fulfil the dream of writing once and running everywhere: React Native, Flutter.
They're trying to solve a very clear and obvious problem: writing the same app more than once is really wasteful. But that's the nature of the game when it comes to runtime-specific apps. The only alternative is to either deliberately limit your audience …or apply the principle of least power/most availability.
The wastefulness of having to write the same app for multiple platforms isn't the only thing that puts me off making native apps. The exclusivity works in two directions. There's the exclusive nature of the runtime that requires a bespoke codebase. There's also the exclusive nature of the app store. It feels like a return to shelves of packaged software with strict system requirements. You can't just walk in and put your software on the shelf. That's the shopkeeper's job.
There is no shopkeeper for the World Wide Web.
Tuesday, March 30th, 2021 3:01pm
Tagged with availability ubiquity technology platforms native email sms web apps frontend development progressive enhancement access
Upgrades and polyfills
I started getting some emails recently from people having issues using The Session. The issues sounded similar—an interactive component that wasn't, well …interacting.
When I asked what device or browser they were using, the answer came back the same: Safari on iPad. But not a new iPad. These were older iPads running older operating systems.
Now, remember, even if I wanted to recommend that they use a different browser, that's not an option:
Safari is the only browser on iOS devices.
I don't mean it's the only browser that ships with iOS devices. I mean it's the only browser that can be installed on iOS devices.
You can install something called Chrome. You can install something called Firefox. Those aren't different web browsers. Under the hood they're using Safari's rendering engine. They have to.
It gets worse. Not only is there no choice when it comes to rendering engines on iOS, but the rendering engine is also tied to the operating system.
If you're on an old Apple laptop, you can at least install an up-to-date version of Firefox or Chrome. But you can't install an up-to-date version of Safari. An up-to-date version of Safari requires an up-to-date version of the operating system.
It's the same on iOS devices—you can't install a newer version of Safari without installing a newer version of iOS. But unlike the laptop scenario, you can't install any version of Firefox of Chrome.
It's disgraceful.
It's particularly frustrating when an older device can't upgrade its operating system. Upgrades for Operating system generally have some hardware requirements. If your device doesn't meet those requirements, you can't upgrade your operating system. That wouldn't matter so much except for the Safari issue. Without an upgraded operating system, your web browsing experience stagnates unnecessarily.
A website feature isn't working so
you need to upgrade your browser which means
you need to upgrade your operating sytem but
you can't upgrade your operating system so
you need to buy a new device.
Apple doesn't allow other browsers to be installed on iOS devices so people have to buy new devices if they want to use the web. Handy for Apple. Bad for users. Really bad for the planet.
It's particularly galling when it comes to iPads. Those are exactly the kind of casual-use devices that shouldn't need to be caught in the wasteful cycle of being used for a while before getting thrown away. I mean, I get why you might want to have a relatively modern phone—a device that's constantly with you that you use all the time—but an iPad is the perfect device to just have lying around. You shouldn't feel pressured to have the latest model if the older version still does the job:
An older tablet makes a great tableside companion in your living room, an effective e-book reader, or a light-duty device for reading mail or checking your favorite websites.
Hang on, though. There's another angle to this. Why should a website demand an up-to-date browser? If the website has been built using the tried and tested approach of progressive enhancement, then everyone should be able to achieve their goals regardless of what browser or device or operating system they're using.
On The Session, I'm using progressive enhancement and feature detection everywhere I can. If, for example, I've got some JavaScript that's going to use querySelectorAll and addEventListener, I'll first test that those methods are available.
if (!document.querySelectorAll || !window.addEventListener) {
// doesn't cut the mustard.
I try not to assume that anything is supported. So why was I getting emails from people with older iPads describing an interaction that wasn't working? A JavaScript error was being thrown somewhere and—because of JavaScript's brittle error-handling—that was causing all the subsequent JavaScript to fail.
I tracked the problem down to a function that was using some DOM methods—matches and closest—as well as the relatively recent JavaScript forEach method. But I had polyfills in place for all of those. Here's the polyfill I'm using for matches and closest. And here's the polyfill I'm using for forEach.
Then I spotted the problem. I was using forEach to loop through the results of querySelectorAll. But the polyfill works on arrays. Technically, the output of querySelectorAll isn't an array. It looks like an array, it quacks like an array, but it's actually a node list.
So I added this polyfill from Chris Ferdinandi.
That did the trick. I checked with the people with those older iPads and everything is now working just fine.
For the record, here's the small collection of polyfills I'm using. Polyfills are supposed to be temporary. At some stage, as everyone upgrades their browsers, I should be able to remove them. But as long as some people are stuck with using an older browser, I have to keep those polyfills around.
I wish that Apple would allow other rendering engines to be installed on iOS devices. But if that's a hell-freezing-over prospect, I wish that Safari updates weren't tied to operating system updates.
Apple may argue that their browser rendering engine and their operating system are deeply intertwingled. That line of defence worked out great for Microsoft in the '90s.
Wednesday, November 11th, 2020 12:44pm
Tagged with apple ios browsers safari mobile ipads upgrades polyfills javascript progressive enhancement frontend development software installation appstores chrome firefox edge choice disempowerment inconsistency
Web browsers on iOS
You can install something called Chrome. You can install something called Firefox. Those aren't different web browsers. Under the hood they're using Safari's rendering engine. They have to. The app store doesn't allow other browsers to be listed. The apps called Chrome and Firefox are little more than skinned versions of Safari.
If you're a web developer, there are two possible reactions to hearing this. One is "Duh! Everyone knows that!". The other is "What‽ I never knew that!"
If you fall into the first category, I'm guessing you've been a web developer for a while. The fact that Safari is the only browser on iOS devices is something you've known for years, and something you assume everyone else knows. It's common knowledge, right?
But if you're relatively new to web development—heck, if you've been doing web development for half a decade—you might fall into the second category. After all, why would anyone tell you that Safari is the only browser on iOS? It's common knowledge, right?
So that's the situation. Safari is the only browser that can run on iOS. The obvious follow-on question is: why?
Apple at this point will respond with something about safety and security, which are certainly important priorities. So let me rephrase the question: why on iOS?
Why can I install Chrome or Firefox or Edge on my Macbook running macOS? If there are safety or security reasons for preventing me from installing those browsers on my iOS device, why don't those same concerns apply to my macOS device?
At one time, the mobile operating system—iOS—was quite different to the desktop operating system—OS X. Over time the gap has narrowed. At this point, the operating systems are converging. That makes sense. An iPhone, an iPad, and a Macbook aren't all that different apart from the form factor. It makes sense that computing devices from the same company would share an underlying operating system.
As this convergence continues, the browser question is going to have to be decided in one direction or the other. As it is, Apple's laptops and desktops strongly encourage you to install software from their app store, though it is still possible to install software by other means. Perhaps they'll decide that their laptops and desktops should only be able to install software from their app store—a decision they could justify with safety and security concerns.
Imagine that situation. You buy a computer. It comes with one web browser pre-installed. You can't install a different web browser on your computer.
You wouldn't stand for it! I mean, Microsoft got fined for anti-competitive behaviour when they pre-bundled their web browser with Windows back in the 90s. You could still install other browsers, but just the act of pre-bundling was seen as an abuse of power. Imagine if Windows never allowed you to install Netscape Navigator?
And yet that's exactly the situation in 2020.
You buy a computing device from Apple. It might be a Macbook. It might be an iPad. It might be an iPhone. But you can only install your choice of web browser on one of those devices. For now.
It is contradictory. It is hypocritical. It is indefensible.
Tuesday, September 22nd, 2020 10:19am
Tagged with apple ios browsers safari mobile desktop macos software installation appstores chrome firefox edge choice disempowerment inconsistency
Future Sync 2020
I was supposed to be in Plymouth yesterday, giving the opening talk at this year's Future Sync conference. Obviously, that train journey never happened, but the conference did.
The organisers gave us speakers the option of pre-recording our talks, which I jumped on. It meant that I wouldn't be reliant on a good internet connection at the crucial moment. It also meant that I was available to provide additional context—mostly in the form of a deluge of hyperlinks—in the chat window that accompanied the livestream.
The whole thing went very smoothly indeed. Here's the video of my talk. It was The Layers Of The Web , which I've only given once before, at Beyond Tellerrand Berlin last November (in the Before Times).
As well as answering questions in the chat room, people were also asking questions in Sli.do. But rather than answering those questions there, I was supposed to respond in a social medium of my choosing. I chose my own website, with copies syndicated to Twitter.
Here are those questions and answers…
The first few questions were about last years's CERN project, which opens the talk:
Based on what you now know from the CERN 2019 WorldWideWeb Rebuild project—what would you have done differently if you had been part of the original 1989 Team?
I responded:
Actually, I think the original WWW project got things mostly right. If anything, I'd correct what came later: cookies and JavaScript—those two technologies (which didn't exist on the web originally) are the source of tracking & surveillance.
The one thing I wish had been done differently is I wish that JavaScript were a same-origin technology from day one:
https://adactio.com/journal/16099
How excited were you when you initially got the call for such an amazing project?
My predictable response:
It was an unbelievable privilege! I was so excited the whole time—I still can hardly believe it really happened!
Later in the presentation, I talked about service workers and progressive web apps. I got a technical question about that:
Is there a limit to the amount of local storage a PWA can use?
I answered:
Great question! Yes, there are limits, but we're generally talking megabytes here. It varies from browser to browser and depends on the available space on the device.
But files stored using the Cache API are less likely to be deleted than files stored in the browser cache.
More worrying is the announcement from Apple to only store files for a week of browser use:
Finally, there was a question about the over-arching theme of the talk…
Great talk, Jeremy. Do you encounter push-back when using the term "Progressive Enhancement"?
Yes! …And that's why I never once used the phrase "progressive enhancement" in my talk. 🙂
There's a lot of misunderstanding of the term. Rather than correct it, I now avoid it:
https://adactio.com/journal/9195
Instead of using the phrase "progressive enhancement", I now talk about the benefits and effects of the technique: resilience, universality, etc.
Friday, April 17th, 2020 9:09am
Tagged with futuresync2020 conference talk presentation questions answers progressive enhancement pwas webapps cern web frontend development speaking
Apple's attack on service workers
Apple aren't the best at developer relations. But, bad as their communications can be, I'm willing to cut them some slack. After all, they're not used to talking with the developer community.
John Wilander wrote a blog post that starts with some excellent news: Full Third-Party Cookie Blocking and More. Safari is catching up to Firefox and disabling third-party cookies by default. Wonderful! I've had third-party cookies disabled for a few years now, and while something occassionally breaks, it's honestly a pretty great experience all around. Denying companies the ability to track users across sites is A Good Thing.
In the same blog post, John said that client-side cookies will be capped to a seven-day lifespan, as previously announced. Just to be clear, this only applies to client-side cookies. If you're setting a cookie on the server, using PHP or some other server-side language, it won't be affected. So persistent logins are still doable.
Then, in an audacious example of burying the lede, towards the end of the blog post, John announces that a whole bunch of other client-side storage technologies will also be capped to seven days. Most of the technologies are APIs that, like cookies, can be used to store data: Indexed DB, Local Storage, and Session Storage (though there's no mention of the Cache API). At the bottom of the list is this:
Service Worker registrations
Okay, let's clear up a few things here (because they have been so poorly communicated in the blog post)…
The seven day timer refers to seven days of Safari usage, not seven calendar days (although, given how often most people use their phones, the two are probably interchangable). So if someone returns to your site within a seven day period of using Safari, the timer resets to zero, and your service worker gets a stay of execution. Lucky you.
This only applies to Safari. So if your site has been added to the home screen and your web app manifest has a value for the "display" property like "standalone" or "full screen", the seven day timer doesn't apply.
That piece of information was missing from the initial blog post. Since the blog post was updated to include this clarification, some people have taken this to mean that progressive web apps aren't affected by the upcoming change. Not true. Only progressive web apps that have been added to the home screen (and that have an appropriate "display" value) will be spared. That's a vanishingly small percentage of progressive web apps, especially on iOS. To add a site to the home screen on iOS, you need to dig and scroll through the share menu to find the right option. And you need to do this unprompted. There is no ambient badging in Safari to indicate that a site is installable. Chrome's install banner isn't perfect, but it's better than nothing.
Just a reminder: a progressive web app is a website that
runs on HTTPS,
has a service worker,
and a web manifest.
Adding to the home screen is something you can do with a progressive web app (or any other website). It is not what defines progressive web apps.
In any case, this move to delete service workers after seven days of using Safari is very odd, and I'm struggling to find the connection to the rest of the blog post, which is about technologies that can store data.
As I understand it, with the crackdown on setting third-party cookies, trackers are moving to first-party technologies. So whereas in the past, a tracking company could tell its customers "Add this script element to your pages", now they have to say "Add this script element and this script file to your pages." That JavaScript file can then store a unique idenitifer on the client. This could be done with a cookie, with Local Storage, or with Indexed DB, for example. But I'm struggling to understand how a service worker script could be used in this way. I'd really like to see some examples of this actually happening.
The best explanation I can come up with for this move by Apple is that it feels like the neatest solution. That's neat as in tidy, not as in nifty. It is definitely not a nifty solution.
If some technologies set by a specific domain are being purged after seven days, then the tidy thing to do is purge all technologies from that domain. Service workers are getting included in that dragnet.
Now, to be fair, browsers and operating systems are free to clean up storage space as they see fit. Caches, Local Storage, Indexed DB—all of those are subject to eventually getting cleaned up.
So I was curious. Wanting to give Apple the benefit of the doubt, I set about trying to find out how long service worker registrations currently last before getting deleted. Maybe this announcement of a seven day time limit would turn out to be not such a big change from current behaviour. Maybe currently service workers last for 90 days, or 60, or just 30.
Nope:
There was no time limit previously.
This is not a minor change. This is a crippling attack on service workers, a technology specifically designed to improve the user experience for return visits, whether it's through improved performance or offline access.
I wouldn't be so stunned had this announcement come with an accompanying feature that would allow Safari users to know when a website is a progressive web app that can be added to the home screen. But Safari continues to ignore the existence of progressive web apps. And now it will actively discourage people from using service workers.
If you'd like to give feedback on this ludicrous development, you can file a bug (down in the cellar in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of the Leopard").
No doubt there will still be plenty of Apple apologists telling us why it's good that Safari has wished service workers into the cornfield. But make no mistake. This is a terrible move by Apple.
I will say this though: given The Situation we're all living in right now, some good ol' fashioned Hot Drama by a browser vendor behaving badly feels almost comforting.
Thursday, March 26th, 2020 1:44pm
Tagged with serviceworkers safari apple ios pwas progressive webapps homescreen browsers frontend development cookies storage offline devices mobile
Install prompt
There's an interesting thread on Github about the tongue-twistingly named beforeinstallpromt JavaScript event.
Let me back up…
Progressive web apps. You know what they are, right? They're websites that have taken their vitamins. Specifically, they're responsive websites that:
are served over HTTPS,
have a web app manifest, and
have a service worker handling the offline scenario.
The web app manifest—a JSON file of metadata—is particularly useful for describing how your site should behave if someone adds it to their home screen. You can specify what icon should be used. You can specify whether the site should launch in a browser or as a standalone app (practically indistinguishable from a native app). You can specify which URL on the site should be used as the starting point when the site is launched from the home screen.
So progressive web apps work just fine when you visit them in a browser, but they really shine when you add them to your home screen. It seems like pretty much everyone is in agreement that adding a progressive web app to your home screen shouldn't be an onerous task. But how does the browser let the user know that it might be a good idea to "install" the web site they're looking at?
The Samsung Internet browser does ambient badging—a + symbol shows up to indicate that a website can be installed. This is a great approach!
I hope that Chrome on Android will also use ambient badging at some point. To start with though, Chrome notified users that a site was installable by popping up a notification at the bottom of the screen. I think these might be called "toasts".
Needless to say, the toast notification wasn't very effective. That's because we web designers and developers have spent years teaching people to immediately dismiss those notifications without even reading them. Accept our cookies! Sign up to our newsletter! Install our native app! Just about anything that's user-hostile gets put in a notification (either a toast or an overlay) and shoved straight in the user's face before they've even had time to start reading the content they came for in the first place. Users will then either:
turn around and leave, or
use muscle memory reach for that X in the corner of the notification.
A tiny fraction of users might actually click on the call to action, possibly by mistake.
Chrome didn't abandon the toast notification for progressive web apps, but it did change when they would appear. Rather than the browser deciding when to show the prompt—usually when the user has just arrived on the site—a new JavaScript event called beforeinstallprompt can be used.
It's a bit weird though. You have to "capture" the event that fires when the prompt would have normally been shown, subdue it, hold on to that event, and then re-release it when you think it should be shown (like when the user has completed a transaction, for example, and having your site on the home screen would genuinely be useful). That's a lot of hoops. Here's the code I use on The Session to only show the installation prompt to users who are logged in.
The end result is that the user is still shown a toast notification, but at least this time it's the site owner who has decided when it will be shown. The Chrome team call this notification "the mini-info bar", and Pete acknowledges that it's not ideal:
The mini-infobar is an interim experience for Chrome on Android as we work towards creating a consistent experience across all platforms that includes an install button into the omnibox.
I think "an install button in the omnibox" means ambient badging in the browser interface, which would be great!
Anyway, back to that thread on Github. Basically, neither Apple nor Mozilla are going to implement the beforeinstallprompt event (well, technically Mozilla have implemented it but they're not going to ship it). That's fair enough. It's an interim solution that's not ideal for all reasons I've already covered.
But there's a lot of pushback. Even if the details of beforeinstallprompt are troublesome, surely there should be some way for site owners to let users know that can—or should—install a progressive web app? As a site owner, I have a lot of sympathy for that viewpoint. But I also understand the security and usability issues that can arise from bad actors abusing this mechanism.
Still, I have to hand it to Chrome: even if we put the beforeinstallprompt event to one side, the browser still has a mechanism for letting users know that a progressive web app can be installed—the mini info bar. It's not a great mechanism, but it's better than nothing. Nothing is precisely what Firefox and Safari currently offer (though Firefox is experimenting with something).
In the case of Safari, not only do they not provide a mechanism for letting the user know that a site can be installed, but since the last iOS update, they've buried the "add to home screen" option even deeper in the "sharing sheet" (the list of options that comes up when you press the incomprehensible rectangle-with-arrow-emerging-from-it icon). You now have to scroll below the fold just to find the "add to home screen" option.
So while I totally get the misgivings about beforeinstallprompt, I feel that a constructive alternative wouldn't go amiss.
And that's all I have to say about that.
Except… there's another interesting angle to that Github thread. There's talk of allowing sites that are launched from the home screen to have access to more features than a site inside a web browser. Usually permissions on the web are explicitly granted or denied on a case-by-case basis: geolocation; notifications; camera access, etc. I think this is the first time I've heard of one action—adding to the home screen—being used as a proxy for implicitly granting more access. Very interesting. Although that idea seems to be roundly rejected here:
A key argument for using installation in this manner is that some APIs are simply so powerful that the drive-by web should not be able to ask for them. However, this document takes the position that installation alone as a restriction is undesirable.
Then again:
I understand that Chromium or Google may hold such a position but Apple's WebKit team may not necessarily agree with such a position.
Tagged with pwas homescreen progressive webapps browsers standards install prompt ui interface permissions manifest
The Web Share API in Safari on iOS
I implemented the Web Share API over on The Session back when it was first available in Chrome in Android. It's a nifty and quite straightforward API that allows websites to make use of the "sharing drawer" that mobile operating systems provide from within a web browser.
I already had sharing buttons that popped open links to Twitter, Facebook, and email. You can see these sharing buttons on individual pages for tunes, recordings, sessions, and so on.
I was already intercepting clicks on those buttons. I didn't have to add too much to also check for support for the Web Share API and trigger that instead:
if (navigator.share) {
navigator.share(
title: document.querySelector('title').textContent,
text: document.querySelector('meta[name="description"]').getAttribute('content'),
url: document.querySelector('link[rel="canonical"]').getAttribute('href')
That worked a treat. As you can see, there are three fields you can pass to the share() method: title, text, and url. You don't have to provide all three.
Earlier this year, Safari on iOS shipped support for the Web Share API. I didn't need to do anything. 'Cause that's how standards work. You can make use of APIs before every browser supports them, and then your website gets better and better as more and more browsers add support.
But I recently discovered something interesting about the iOS implementation.
When the share() method is triggered, iOS provides multiple ways of sharing: Messages, Airdrop, email, and so on. But the simplest option is the one labelled "copy", which copies to the clipboard.
Here's the thing: if you've provided a text parameter to the share() method then that's what's going to get copied to the clipboard—not the URL.
That's a shame. Personally, I think the url field should take precedence. But I don't think this is a bug, per se. There's nothing in the spec to say how operating systems should handle the data sent via the Web Share API. Still, I think it's a bit counterintuitive. If I'm looking at a web page, and I opt to share it, then surely the URL is the most important piece of data?
I'm not even sure where to direct this feedback. I guess it's under the purview of the Safari team, but it also touches on OS-level interactions. Either way, I hope that somebody at Apple will consider changing the current behaviour for copying Web Share data to the clipboard.
In the meantime, I've decided to update my code to remove the text parameter:
If the behaviour of Safari on iOS changes, I'll reinstate the missing field.
By the way, if you're making progressive web apps that have display: standalone in the web app manifest, please consider using the Web Share API. When you remove the browser chrome, you're removing the ability for users to easily share URLs. The Web Share API gives you a way to reinstate that functionality.
Wednesday, October 16th, 2019 11:48am
Tagged with webshare api ios safari sharing clipboard copying mobile ux ui interface browsers standards pwas progressive webapps frontend development
It's browser updatin' time! Firefox 65 just dropped. So did Chrome 72. Safari 12.1 is shipping with iOS 12.2.
It's interesting to compare the release notes for each browser and see the different priorities reflected in them (this is another reason why browser diversity is A Good Thing).
A lot of the Firefox changes are updates to dev tools; they just keep getting better and better. In fact, I'm not sure "dev tools" is the right word for them. With their focus on layout, typography, and accessibility, "design tools" might be a better term.
Oh, and Firefox is shipping support for some CSS properties that really help with print style sheets, so I'm disproportionately pleased about that.
In Safari's changes, I'm pleased to see that the datalist element is finally getting implemented. I've been a fan of that element for many years now. (Am I a dork for having favourite HTML elements? Or am I a dork for even having to ask that question?)
And, of course, it wouldn't be a Safari release without a new made up meta tag. From the people who brought you such hits as viewport and apple-mobile-web-app-capable, comes …supported-color-schemes (Apple likes to make up meta tags almost as much as Google likes to make up rel values).
There'll be a whole bunch of improvements in how progressive web apps will behave once they've been added to the home screen. We'll finally get some state persistence if you navigate away from the window!
Updated the behavior of websites saved to the home screen on iOS to pause in the background instead of relaunching each time.
Maximiliano Firtman has a detailed list of the good, the bad, and the "not sure yet if good" for progressive web apps on iOS 12.2 beta. Thomas Steiner has also written up the progress of progressive web apps in iOS 12.2 beta. Both are published on Ev's blog.
At first glance, the release notes for Chrome 72 are somewhat paltry. The big news doesn't even seem to be listed there. Maximiliano Firtman again:
Chrome 72 for Android shipped the long-awaited Trusted Web Activity feature, which means we can now distribute PWAs in the Google Play Store!
Very interesting indeed! I'm not sure if I'm ready to face the Kafkaesque process of trying to add something to the Google Play Store just yet, but it's great to know that I can. Combined with the improvements coming in iOS 12.2, these are exciting times for progressive web apps!
Friday, February 1st, 2019 6:21pm
Tagged with browsers standards firefox safari chrome pwas progressive webapps homescreen ios android frontend development datalist devtools updates
Greater expectations
I got an intriguing email recently from someone who's a member of The Session, the community website about Irish traditional music that I run. They said:
When I recently joined, I used my tablet to join. Somewhere I was able to download The Session app onto my tablet.
But there is no native app for The Session. Although, as it's a site that I built, it is, a of course, progressive web app.
They went on to say:
I wanted to put the app on my phone but I can't find the app to download it. Can I have the app on more than one device? If so, where is it available?
I replied saying that yes, you can absolutely have it on more than one device:
But you don't find The Session app in the app store. Instead you go to the website https://thesession.org and then add it to your home screen from your browser.
My guess is that this person had added The Session to the home screen of their Android tablet, probably following the "add to home screen" prompt. I recently added some code to use the window.beforeinstallprompt event so that the "add to home screen" prompt would only be shown to visitors who sign up or log in to The Session—a good indicator of engagement, I reckon, and it should reduce the chance of the prompt being dismissed out of hand.
So this person added The Session to their home screen—probably as a result of being prompted—and then used it just like any other app. At some point, they didn't even remember how the app got installed:
Success! I did it. Thanks. My problem was I was looking for an app to download.
On the one hand, this is kind of great: here's an example where, in the user's mind, there's literally no difference between the experience of using a progressive web app and using a native app. Win!
But on the other hand, the expectation is still that apps are to be found in an app store, not on the web. This expectation is something I wrote about recently (and Justin wrote a response to that post). I finished by saying:
Perhaps the inertia we think we're battling against isn't such a problem as long as we give people a fast, reliable, engaging experience.
When this member of The Session said "My problem was I was looking for an app to download", I responded by saying:
Well, I take that as a compliment—the fact that once the site is added to your home screen, it feels just like a native app. :-)
And they said:
Yes, it does!
Friday, August 3rd, 2018 10:13am
Tagged with pwas progressive webapps thesession mobile native appstores android expectations install homescreen prompt ux frontend development
Altering expectations
Luke has written up the selection process he went through when Clearleft was designing the Virgin Holidays app. When it comes to deploying on mobile, there were three options:
Native apps
A progressive web app
A hybrid app
The Virgin Holidays team went with that third option.
Now, it will come as no surprise that I'm a big fan of the second option: building a progressive web app (or turning an existing site into a progressive web app). I think a progressive web app is a great solution for travel apps, and the use-case that Luke describes sounds perfect:
Easy access to resort staff and holiday details that could be viewed offline to help as many customers as possible travel without stress and enjoy a fantastic holiday
Luke explains why they choice not to go with a progressive web app.
The current level of support and leap in understanding meant we'd risk alienating many of our customers.
The issue of support is one that is largely fixed at this point. When Clearleft was working on the Virgin Holidays app, service workers hadn't landed in iOS. Hence, the risk of alienating a lot of customers. But now that Mobile Safari has offline capabilities, that's no longer a problem.
But it's the second reason that's trickier:
Simply put, customers already expected to find us in the App Store and are familiar with what apps can historically offer over websites.
I think this is the biggest challenge facing progressive web apps: battling expectations.
For over a decade, people have formed ideas about what to expect from the web and what to expect from native. From a technical perspective, native and web have become closer and closer in capabilities. But people's expectations move slower than technological changes.
First of all, there's the whole issue of discovery: will people understand that they can "install" a website and expect it to behave exactly like a native app? This is where install prompts and ambient badging come in. I think ambient badging is the way to go, but it's still a tricky concept to explain to people.
But there's another way of looking at the current situation. Instead of seeing people's expectations as a negative factor, maybe it's an opportunity. There's an opportunity right now for companies to be as groundbreaking and trendsetting as Wired.com when it switched to CSS for layout, or The Boston Globe when it launched its responsive site.
It makes for a great story. Just look at the Pinterest progressive web app for an example (skip to the end to get to the numbers):
Weekly active users on mobile web have increased 103 percent year-over-year overall, with a 156 percent increase in Brazil and 312 percent increase in India. On the engagement side, session length increased by 296 percent, the number of Pins seen increased by 401 percent and people were 295 percent more likely to save a Pin to a board. Those are amazing in and of themselves, but the growth front is where things really shined. Logins increased by 370 percent and new signups increased by 843 percent year-over-year. Since we shipped the new experience, mobile web has become the top platform for new signups. And for fun, in less than 6 months since fully shipping, we already have 800 thousand weekly users using our PWA like a native app (from their homescreen).
Now admittedly their previous mobile web experience was a dreadful doorslam, but still, those are some amazing statistics!
Maybe we're underestimating the malleability of people's expectations when it comes to the web on mobile. Perhaps the inertia we think we're battling against isn't such a problem as long as we give people a fast, reliable, engaging experience.
If you build that, they will come.
Tuesday, July 24th, 2018 2:39pm
Tagged with pwas progressive webapps businesses brands commerce offline experience serviceworkers ux marketing travel clearleft virgin native mobile badging expectations
Twitter and Instagram progressive web apps
Since support for service workers landed in Mobile Safari on iOS, I've been trying a little experiment. Can I replace some of the native apps I use with progressive web apps?
The two major candidates are Twitter and Instagram. I added them to my home screen, and banished the native apps off to a separate screen. I've been using both progressive web apps for a few months now, and I have to say, they're pretty darn great.
There are a few limitations compared to the native apps. On Twitter, if you follow a link from a tweet, it pops open in Safari, which is fine, but when you return to Twitter, it loads anew. This isn't any fault of Twitter—this is the way that web apps have worked on iOS ever since they introduced their weird web-app-capable meta element. I hope this behaviour will be fixed in a future update.
Also, until we get web notifications on iOS, I need to keep the Twitter native app around if I want to be notified of a direct message (the only notification I allow).
Apart from those two little issues though, Twitter Lite is on par with the native app.
Instagram is also pretty great. It too suffers from some navigation issues. If I click through to someone's profile, and then return to the main feed, it also loads it anew, losing my place. It would be great if this could be fixed.
For some reason, the Instagram web app doesn't allow uploading multiple photos …which is weird, because I can upload multiple photos on my own site by adding the multiple attribute to the input type="file" in my posting interface.
Apart from that, though, it works great. And as I never wanted notifications from Instagram anyway, the lack of web notifications doesn't bother me at all. In fact, because the progressive web app doesn't keep nagging me about enabling notifications, it's a more pleasant experience overall.
Something else that was really annoying with the native app was the preponderance of advertisements. It was really getting out of hand.
Well …(looks around to make sure no one is listening)… don't tell anyone, but the Instagram progressive web app—i.e. the website—doesn't have any ads at all!
Here's hoping it stays that way.
Tagged with serviceworkers pwas twitter instagram progressive webapps native homescreen ux mobile ios safari notifications


text:
Advocacy Groups Seek to Curb Corporations
By Eliza Newlin Carney
Posted November 28, 2011 at 6:24pm
As Occupy Wall Street activists vacate public parks around the country, several new advocacy groups have sprung up to pursue OWS-inspired constitutional amendments to limit the influence of money and corporate lobbying in politics.
The idea of amending the Constitution to overturn "corporate personhood" has also taken hold on Capitol Hill, spawning a half-dozen resolutions in the House and Senate. These include three separate amendments introduced this month by Reps. Ted Deutch (D-Fla.), Jim McGovern (D-Mass.) and Betty Sutton (D-Ohio).
"I think the Occupy energy that's sweeping across America is a huge wave, and anybody who doesn't get a surfboard on top of it is losing a tremendous opportunity," said Nick Penniman, president of United Republic, a new nonprofit that's set out to fight what organizers call "the corrupting influence of well-financed special interests."
The group moved up its launch date, Penniman said, in part to tap the energy behind the Occupy movement, which lacks a specific agenda but which has spotlighted anti-corporate slogans in cities around the country. Co-founded by Josh Silver, former CEO of the media and technology reform group Free Press, United Republic already has a staff of about a dozen people and plans a $10 million budget for 2012.
Another pro-reform activist who rushed to open his doors this fall is Cenk Uygur, a left-leaning Internet talk-radio host who has launched a group called Wolf PAC to push for a constitutional amendment to get big money out of politics. Uygur, who hosts the show "The Young Turks" and formerly hosted a program on MSNBC, announced the launch in a spirited call-and-response rally with Occupy Wall Street protesters in lower Manhattan last month.
"Corporations are not people," Uygur shouted to a gathering of Occupy activists, who chanted back, "Corporations are not people."
Uygur has rounded up 42,000 volunteers all over the country and will soon hire an executive director for his group, he said. Wolf PAC will operate as an unrestricted super political action committee and will focus first on amending the Constitution through the states, and not through Congress. (Any constitutional amendment must be approved by a two-thirds majority of the House and the Senate and ratified by three-fourths of the states.)
"We're not kidding around," Uygur said in an interview. "It's going to be very aggressive. We will pressure the state legislators through calls, possibly occupying state houses."
United Republic and Wolf PAC join an already existing cluster of pro-reform groups formed in the wake of the Supreme Court's landmark Citizens United v. Federal Election Commission ruling early last year. That ruling freed both corporations and unions to spend unrestricted organizational money on campaigns.
Groups spawned by the ruling include Move to Amend, a coalition of liberal organizations pushing to amend the Constitution to establish that political spending does not deserve the same protections as free speech; We the People, launched by a trio of progressives that includes Katrina vanden Heuvel, editor and publisher of the Nation; and Free Speech for People, which is pushing a constitutional amendment to establish that "free speech and other Constitutional rights are for people, not corporations."
"For the first time now, Congress has the opportunity to debate this basic question of whether corporations should be treated as people with constitutional rights," said John Bonifaz, who co-
founded Free Speech for People the day after the Citizens United ruling with Boston lawyer Jeff Clements. Clements has just authored a forthcoming book titled "Corporations Are Not People: Why They Have More Rights Than You Do and What You Can Do About It."
Given the large majorities needed to amend the Constitution at both the federal and the state level, lawmakers and activists pushing for constitutional changes face an uphill battle. They are also up against free-speech advocates who argue that amendments targeting corporations violate constitutional First Amendment rights.
"Silencing one group may be politically beneficial in the short-term for certain groups," wrote Joe Trotter, media manager of the pro-free-speech Center for Competitive Politics, in a recent FrumForum blog post on recent anti-corporate rhetoric. "However, it ultimately leaves everyone worse off because it creates a knowledge vacuum. In our society, public and private sectors are hopelessly intertwined. It does everyone a disservice to hold only one group responsible."
Some of the new groups organizing in the name of reform, moreover, are using the same tactics as the corporate-backed political groups they criticize. Uygur's Wolf PAC will be free to raise and spend unrestricted money, something that was not permitted through PACs before Citizens United. As a nonprofit, United Republic faces no obligation to disclose its funding sources — not unlike the new corporate-backed political nonprofits that reform advocates deplore.
At the same time, the proliferation of activists taking aim at big corporate money offers Occupy activists some tangible goals beyond simply sleeping in parks. One of United Republic's objectives, Penniman said, is to help firm up specific short-term and long-term goals for the nascent anti-corporate-reform movement, which has yet to articulate a uniform approach to amending the Constitution.
"One of our hopes is that we'll be able to coalesce the reform community around a common strategy for both amending the Constitution in the long haul, [and] also figuring out what the short-term victories are between now and a Constitutional amendment," Penniman said.
His group's goals include a "main street communications strategy" to "de-wonkify" the money and politics issue and help average Americans grasp how campaign spending affects their daily lives. The group will reach out to both political parties and is recruiting board members who are Democrats, Republicans and independents, he said.
Uygur, too, said anti-corporate sentiment transcends political party: "Everybody gets it. The tea party and Occupy Wall Street have the same core issue, which is: I don't think these guys [in Washington, D.C.] are on the level. Whether it's Democrats or Republicans, these guys don't represent us."

redpajama_set_name: RedPajamaCommonCrawl


text:
Phaéton (ou Phaëton, né en 1871, mort en 1896) est un étalon trotteur anglo-normand, fils du Pur-sang The Heir of Linne, considéré comme un étalon fondateur de la race du Trotteur français. Compétiteur moyen, ce cheval issu de croisements entre Pur-sang et Trotteur Norfolk se fait essentiellement connaître grâce aux excellentes performances de ses descendants, durant sa carrière d'étalon au haras national du Pin. Phaéton devient l'un des quatre grands fondateurs du Trotteur français moderne, avec les étalons Normand, Conquérant et Lavater.

Phaéton est un étalon alezan d', fortement marqué de blanc et réputé pour sa belle apparence, malgré son défaut héréditaire de conformation des jarrets. Sa lignée mâle perdure grâce à son fils James Watt, la lignée de son meilleur fils, Harley, ayant disparu.

Dénomination
Le journaliste et historien Jean-Pierre Reynaldo (1949-2014) orthographie le nom de ce cheval « Phaëton », précisant qu'il est également nommé « Phaéton ». Dans L'Élevage du trotteur en France (1896), Paul Guillerot emploie le nom de « Phaëton », de même qu'Albert Viel (1923) ; en revanche Louis Baume (Influence des courses au trot sur la production chevaline en France, 1913), et l'article anonyme signé « Trotting » dans le Sport universel illustré en 1901, écrivent « Phaéton ».

Histoire

Phaéton naît en 1871 à Saint-André-de-Bohon, près de Carentan, chez l'éleveur Jules Lécuyer, dans le département de la Manche en Normandie, en France. Il provient d'un croisement entre trotteur et galopeur (Pur-sang), que Paul Guillerot nomme . Contrairement à de nombreux chevaux issus de ce type de croisement, Phaéton a conservé une aptitude au trot uniquement.

Il est acheté à l'âge du sevrage par M. L. (ou Edmond) Revel, qui le présente sur les pistes d'hippodrome sous ses couleurs. Sa carrière sportive se révèle moyenne au regard du faible nombre de compétiteurs en course de trot à son époque. Il court à l'âge de 3 et , gagnant quatre des courses auxquelles il participe, avec une réduction kilométrique maximale de , mesure relativement incertaine.

Saison de course de 3 ans
Phaéton débute au derby de Rouen, bouclant les  en  à la seconde place, derrière un fils de l'étalon Conquérant, Plaisir des Dames. La seconde course à laquelle il participe est le prix du conseil général de la Manche, à Cherbourg, qui accueille trois concurrents, et au cours duquel il est battu par Oak, un cheval du duc de Vicence, et bat son demi-frère Pactole. Lors de sa sortie à Cabourg, il est battu par Pourquoi Pas et par un autre de ses demi-frères, Prince. Il obtient sa première victoire à l'hippodrome du Pin, en battant les chevaux Pactole, Pique Hardy, Plaisir des Dames, Pourquoi Pas, et plusieurs autres compétiteurs. Sa saison de course se termine sur un échec durant l'épreuve d'étalons de Caen, où il termine à la sixième place derrière des chevaux de , et derrière Pactole. Ses gains pour sa saison de  s'élèvent à , son meilleur temps étant de  sur  lors de sa victoire au Pin.

Saison de course de 4 ans
En 1875, Phaéton commence sa saison de course de  sur un échec à Morlaix, battu par son demi-frère Pactole. Sa seconde course de la saison, le Prix du conseil général à Caen, s'achève sur une victoire face aux chevaux Quinola et Prince. Il réitère sa bonne performance à Falaise, en battant Plaisir des Dames. Il est présenté à l'épreuve d'étalons de Tarbes et l'emporte sur tous les autres chevaux de la région. Sa dernière course est courue à Caen, où il termine  derrière Pactole et Pourquoi Pas. Sa saison de  s'achève sur  de gains et une réduction kilométrique améliorée à .

Statistiquement, Phaéton n'est pas le meilleur trotteur de sa génération, s'étant montré sensiblement égal à Plaisir des Dames et Pourquoi Pas, et moins bon que son demi-frère Pactole.

Carrière de reproducteur au haras du Pin

Phaéton est acheté par les Haras nationaux, pour la somme de , et envoyé au haras national du Pin. Il y est voué à la reproduction jusqu'à sa mort, survenue en 1896, à l'exception des années 1884 et 1885 durant lesquelles il fait la monte dans le Calvados.

Au début de sa carrière de reproducteur, il semble avoir peu attiré les éleveurs de l'Orne. Ses premiers poulains courent en 1880, mais il faut attendre 1885 pour que de grands compétiteurs établissent la réputation de Phaéton en tant qu'étalon. En 1886, Phaéton devient tête de liste des étalons trotteurs, et conserve cette position jusqu'en 1889. Il fait alors la fortune des éleveurs qui ont gardé ses filles comme juments poulinières.

Phaéton meurt durant les premières semaines de l'année 1896.

Description

Phaéton est réputé pour sa belle apparence, trahissant ses origines Pur-sang ; il l'est en effet aux trois-quarts. Jean-Pierre Reynaldo le classe comme étant de race Anglo-normand, tandis que la base de données Infochevaux de l'Institut français du cheval et de l'équitation inscrit Phaéton comme un Trotteur français.

L'étalon est décrit dans Le Sport universel illustré du  comme un  de robe alezan dorée, doté de deux balzanes aux membres postérieurs et d'une large liste en tête, et toisant  au garrot. Sa morphologie rappelle le cheval de selle, avec de grandes lignes et un rein court. Sa hanche est relativement ronde, la poitrine et la sortie d'encolure sont réputées parfaites. Son attache de tête rappelle le Pur-sang. Ses tissus sont particulièrement fins. Ses jambes sont dépourvues de fanons.

Il lui est reproché d'avoir la gouttière derrière le jardon trop étroite, donnant un jarret , un défaut de conformation qui a été transmis à ses descendants.

Son caractère est réputé avoir été difficile durant ses jeunes années, puis s'être adouci au fil du temps.

Origines

Le comte de Comminges cite le pedigree de Phaéton en insistant sur la présence d'ancêtres Pur-sang. Édouard Nicard estime que les origines Pur-sang de Phaéton sont d'environ 60 %. L'autre origine  que Phaéton partage avec d'autres étalons fondateur du Trotteur français est celle des trotteurs du Norfolk. Phaéton est donc marqué par une double origine entre Pur-sang galopeur dans sa lignée paternelle, et un mélange entre Trotteur Norfolk et demi-sang de chasse anglais dans sa lignée maternelle. Édouard Nicard estime que l'alliance entre le Pur-sang et le Trotteur Norfolk fait le succès de Phaéton en tant que reproducteur, la première origine conférant la vitesse, la seconde l'aptitude à trotter. Louis Baume estime que Phaéton a puisé l'aptitude à trotter chez sa mère, et souligne que la région de Carentan est le berceau de deux autres étalons fondateurs du Trotteur français : Conquérant et Fuschia ; il l'attribue à l'influence des courses au trot tenues à Cherbourg et à Saint-Lô.

Les étalons Conquérant et Normand descendent du fondateur du Pur-sang Godolphin Arabian, mais Phaéton est un descendant en lignée mâle de Darley Arabian, par son père Pur-sang The Heir of Linne (dont il est le fils le plus connu). The Heir of Linne a participé à la prestigieuse Goodwood Cup, puis a été importé des îles Britanniques. Il est acquis par le haras national de Saint-Lô en 1859. C'est un étalon plutôt léger et fin, doté d'une longue encolure. Son influence modifie le style de trot des chevaux, tendant à remplacer le mouvement du genou par un trot plus long et étendu, presque rasant. Des treize fils trotteurs de ce Pur-sang, seul Phaéton passe à la postérité. The Heir of Linne est également le père de Modestie, elle-même mère de Tigris. C'est aussi un lointain descendant d'Eclipse. La grand-mère paternelle de Phaéton, à l'origine nommée Louisa Newell, puis rebaptisée Mistress Walkers, a effectué une carrière en course en Angleterre et en France où, face à ses mauvais résultats, elle fut vendue.

La mère de Phaéton, la jument La Crocus (nommée « Ambition » par Edmond Gast), par ses parents Crocus et Élisa, est aussi une demi-sœur de Conquérant. C'est une jument que Reynaldo décrit comme , très imprégnée de sang Norfolk, et mal conformée des jarrets. Phaéton est son seul poulain connu, car La Crocus était difficile à faire saillir, aussi son éleveur la vendit après son premier poulinage. D'après le Sport universel illustré, les trois autres poulains de cette jument se sont révélés médiocres.

Élisa (ou « Jeune Élisa » pour la différencier de sa mère portant le même nom) est une jument présente dans la grande majorité des généalogies du Trotteur français ; elle a couru à Falaise, au Pin, à La Meauffe et à Avranches en 1856. Ses origines sont marquées par le Trotteur Norfolk et le Pur-sang. Sa mère, Élisa ou Élise, qualifiée de « poulinière anglo-poitevine » par Edmond Gast, fut la propriété de Joseph Lafosse qui l'a achetée sur les conseils du baron de Taya, directeur du haras national de Saint-Lô. Le père de la Jeune Élisa, Corsair, est un étalon alezan d', né en 1845, qui a fait la monte à Saint-Lô entre 1852 et 1860.

Les informations généalogiques à son sujet sont présentes dans différentes bases de données, dont HorseTelex, Infochevaux}, ainsi que dans des ouvrages d'époque par Nicard et Gast.

Phaéton est un neveu de deux autres grands étalons fondateurs du Trotteur français Conquérant et Lavater. Un aspect marquant dans ses origines est donc la présence d'ancêtres communs à d'autres grands étalons fondateurs de la race du Trotteur français, entraînant . The Heir of Linne est un neveu de l'étalon Conquérant, l'étalon Tigris étant issu de Lavater et de la jument Modestie, une fille de The Heir of Linne.

Descendance

D'après Guillerot (1896), Phaëton est un étalon remarquable. Ses descendants montrent une disposition naturelle pour le trot, attribuée à l'influence de l'étalon The Heir of Linne. D'après le Sport universel illustré du , . Ses fils et filles héritent de sa distinction et de ses grandes lignes, de tissus fins et de beaux crins , les seuls défauts morphologiques transmis et relevés étant une cuisse trop courte, un rognon trop plat, et, plus dommageable, le jardon. Ses descendants héritent aussi fréquemment de ses marques blanches étendues, et parfois de marques blanches sous le ventre. Il transmet un modèle de bon cheval de selle, proche du Pur-sang.

Phaéton est considéré comme un étalon fondateur de la race du Trotteur français ; les « Que sais-je ? » (édition de 1967 et édition de 1982) consacrés aux courses de chevaux le placent parmi les cinq étalons nés dans les années 1870 et dont descendent 90 % des chevaux de race Trotteur français actuels. Le croisement classique dont sont issus les Trotteurs français du début du  est un croisement entre la lignée de Fuschia et la sienne.

En 1901, sur trente-huit étalons trotteurs disponibles au haras du Pin, dix-huit sont descendants de Phaëton.

Fils et filles

Albert Viel et Reynaldo dénombrent  fils ou filles de Phaéton. Ses filles se sont révélées meilleures compétitrices que ses fils.

Guillerot cite, parmi les meilleurs fils de Phaéton, les étalons Harley, James Watt, Kachemyr (ou Kaschmyr), Napoléon, Galba et Levraut. Le Sport universel illustré ajoute Narcisse à la liste des meilleurs fils de Phaéton. Louis Baume cite Harley et James Watt comme les deux meilleurs fils de Phaéton, Ollivier y ajoutant Narcisse. L'étalon Napoléon () aurait pu rejoindre ce trio, mais il est mort précocement.

Parmi les filles, Guillerot cite Aiglonne (), Diva (), Dulcinée (mère de Messagère), Ellora (), Escapade (mère d'Osmonde par Fuschia), Étincelle (), Finlande (, gagnante du derby de Rouen et de  son année de ), Flore (), Gérance (), Javotte (), Kyrielle (), Lydia (), Mandragore (), Néva (), Nitouche () et Tricoteuse (), parmi les plus remarquables. Ellora, notamment, établit un record de vitesse à  et gagne  durant sa carrière. Escapade, compétitrice remarquable, se fait encore plus distinguer comme jument poulinière.

Phaéton a de très nombreux autres poulains, dont certains de qualité très ordinaire, tels qu'Elski et Emir. Parmi ses poulains figurent Jaloux (ex-Jalon), par la jument Lucrèce, gagnant de  à  ; Sans Nom (par Zaïne) ; Italien, par la jument Rainette, Favorite,  et Flibustier, par la jument Voltigeuse, considéré comme son meilleur fils à l'époque. Une note manuscrite dans l'ouvrage de Guillerot, reprise par Albert Viel, signale que la jument Ergoline (mère du célèbre Bémécourt) est une fille de Phaéton, et non d'Écho, considéré comme un étalon médiocre : le personnel des Haras manquait de cartes de saillie pour Phaéton, si bien qu'une carte d'Écho fut donnée pour la saillie de la mère d'Ergoline, Camélia. La jument Bonne Mère est une fille de Typique ou de Phaéton, par Harmonie, qui a gagné  en course entre ses  et ses , pour une réduction kilométrique de . Belle Charlotte, autre fille de Phaéton par Harmonie, a gagné  en course l'année de ses .

Petits-fils et petites-filles

Croisées avec le chef de race Fuschia, les filles de Phaéton ont donné naissance à d'excellents trotteurs tels que Messagère, Nitouche, Hérode, Hetman et Osmonde. D'après Maurice de Gasté (Le Modèle et les Allures, 1908), .

Parmi les petits-fils de Phaéton en lignée maternelle, on peut citer Intérim (par Acquila) ; Soubrette (par Arcole) ; , , Ilote, Jaquar, Jaseuse et Kerisper (tous issus de l'étalon Beaugé) ; Aurore, Iéna, , Kagoula, Kaviar, Kyrielle, Laura, Marcelet, Mimosa, Miracle, Myosotis, Nabucho, Narcisse (par , gagnante de  à ), Nemea, Nevada, Offembach, Orfa, Pastourelle, Pénéloppe, Pensez Y, Perfica, Perle Fine et Petite Chance (par Cherbourg) ; Gallia, Héroïne et Œil de Bœuf (par Dictateur) ; La France, Mina et Quenotte (par Don Quichotte) ; Marie Louise (par Écho) ; Gavotte, Icarie, Jéricho, Jitomir, Jonquille, Jouvence, Kalmie, Kermes, Kiffis, Laïs, Lancelot, Lavardin, Léopard, Limier, Mancelie, Mancini, Marengo, Mignarde, Minerve, Nageur, Nitouche, Ochosias, Ostende, Ouvreuse, Pembroke, Perette, Picolo, Qu'y Met On, Rose Noire, Soubrette, Tirelire et Tubéreuse ;  Herman, Kadéja, Kerman, Kina, Koléah, Lavoisier, Liancourt, Louveteau, Mamertin, Mandarine, Mica, Montrésor, Nautilus, Nonantaise, Normandelle, Ohio, Orangère, Pétillante et Quotiant (par Élan) ; Lanleff, Luron, Ma Cousine, Nicotine, Novice (par Étendard) ; La Fresnaye, Léonidas et Lina (par Fier à Bras).

Lignée de Phaéton

Lorsqu'il établit les pedigree des Trotteurs français pour son étude de 1896, Paul Guillerot classe Phaéton comme  issu de la souche du Pur-sang The Heir of Linne. En 1913, Louis Baume établit quatre grandes lignées chez le Trotteur français : celles de Conquérant, de Normand, de Lavater et celle de Phaéton. Ces lignées se sont mélangées entre elles, réduisant quelque peu l'importante consanguinité des débuts de croisements entre les descendants de Fuschia et ceux de Phaéton, chez le Trotteur français.

La lignée mâle de Phaéton n'a survécu que grâce à son fils James Watt, qui a donné un seul bon étalon, Uranus, père du remarquable Enoch.

Le Sport universel illustré considère que Harley est un meilleur étalon, dont le seul défaut réside dans les aplombs des antérieurs. Sa lignée aurait disparu si  n'avait pas accueilli l'étalon franco-russe Virois, père de , lui-même mort sans descendant mâle pour perpétuer sa lignée.

Dans son ouvrage de 2015, Jean-Pierre Reynaldo cite la « lignée de Phaëton » à laquelle il attribue le numéro « 3 », et qu'il divise elle-même en trois rameaux : celui d'Enfant de Troupe (3a) ; celui de Javari (3b) qui a été propagé grâce aux étalons Quioco et Jiosco ; celui de Janus (3c). Ces trois rameaux partent de trois fils de l'étalon Quo Vadis.

Notes et références

Note

Sources anciennes

Références récentes

Références issues de bases de données

Annexes
Prix Phaeton

Bibliographie
.

Animal né dans les années 1870
Trotteur français
Animal né dans la Manche
Étalon chef de race
Anglo-normand
Monde équestre en Normandie
Animal mort dans les années 1890

redpajama_set_name: RedPajamaWikipedia


text:
El municipio de Grant (en inglés: Grant Township) es un municipio ubicado en el condado de Vermilion en el estado estadounidense de Illinois. En el año 2010 tenía una población de 6028 habitantes y una densidad poblacional de 26,85 personas por km².

Geografía
El municipio de Grant se encuentra ubicado en las coordenadas . Según la Oficina del Censo de los Estados Unidos, el municipio tiene una superficie total de 224.54 km², de la cual 224,46 km² corresponden a tierra firme y (0,04 %) 0,08 km² es agua.

Demografía
Según el censo de 2010, había 6028 personas residiendo en el municipio de Grant. La densidad de población era de 26,85 hab./km². De los 6028 habitantes, el municipio de Grant estaba compuesto por el 93,3 % blancos, el 0,88 % eran afroamericanos, el 0,43 % eran amerindios, el 0,28 % eran asiáticos, el 3,85 % eran de otras razas y el 1,26 % eran de una mezcla de razas. Del total de la población el 9,72 % eran hispanos o latinos de cualquier raza.

Referencias

Enlaces externos

Municipios de Illinois
Localidades del condado de Vermilion (Illinois)