DirecTV has announced that they will only support Internet Explorer starting in July. Sorry, my bad. They will only support Chrome. Still, just as bad a move.
When jQuery first came out in 2006, it was built around browser-detection based forking. If IE, do things this way; if Firefox, do things this way. It wasn’t long before they abandoned that and went to feature-detection. If the browser supported this feature, do things this way; otherwise, do things this way.
When iPhones first hit, the popular thing was to look for a user-agent string that included iPhone. If present, deliver an iPhone experience. Then responsive web design hit in 2010 and we started targeting screen dimensions.
This was the push for the longest time. Get away from detecting browsers and specific devices. Look instead at what the browser and device are capable of, and progressively enhance the UX from there. Build for the lowest common denominator.
And, to make matters worse, we are starting to see developers getting back to supporting specific browsers. When your front-end uses very specific, new technologies, that is the choice a developer has to make. Either a) don’t use it, as the support isn’t great yet; b) use progressive enhancement and provide a feature when available; c) find a polyfill to provide support to the greatest number of users. There should be no d) only support Chrome.
If you don’t learn your history, you are damned to repeat it.
Using a framework is not always bad, outsourcing your understanding of the basic languages of front-end development to one is definitely bad.
Great article on CSS support, making everything look the same everywhere, and more. This line, though, stood out to me. It’s an argument I frequently find myself in. Everyone knows that I hate Bootstrap. The why is what they don’t often understand. That line sums it up.
Have you outsourced your understanding of the basic languages to a framework?
Personal sites, our blogs, these were once our playgrounds. My own site was the first place I added rollover images, CSS for fonts, tried out a “table free” design. I wrote about the web, surrounded by my own experiments with the web. We all did, and it was only in reading those words from 1999 that I realised there was more to owning your own content than simply not publishing your words elsewhere.
My first blog was called Cochon d’Vol, butchered French for the Flying Pig. It was on a blogging system I built in PHP called Blog Wizard. I put a lot of work into that blogging system. Even had a logo. Never intended to release it. But it was mine. And the site went through a redesign every few months. Because that’s what we did back then.
That was a lot of work. Sites like MySpace were much easier for publishing content. And MySpace, unlike its predecessors, allowed for custom CSS to be injected by users, making each MySpace profile an experience. Usually a gaudy experience with animated backgrounds and poorly chosen colors. And then came Facebook. More refined, less targetted at children. Just publishing.
We lost sight of the importance of our own domains. Photos went up to Instagram. Every thought that came to mind went up to Twitter. But our oasis, our experimental island, was lost. Over the last year or two many of my favorite writers in web development have returned to their blogs. I have done my best to do the same. The temptation of tweeting is hard. Look at President-Elect Trump. Finding a happy medium— a pattern of what goes to those centralized networks and what goes to my own site— takes time and intentionality.
But here I can play. A refresh of this site will be coming soon, something I started working towards right after New Years. After a tumultuous 2016, I finally updated Ghost to the latest and greatest version, gaining a lot of functionality that I hadn’t had before and started planning around an updated look. Let’s return to writing refined, thoughtful articles instead of spontaneous, haphazard thoughts. Let’s return to our playgrounds.
The codebase on big sites isn’t impenetrable because developers slavishly followed arbitrary best practices. The codebase is broken because developers don’t talk to each other and don’t make style guides or pattern libraries. And they don’t do those things because the people who hire them force them to work faster instead of better. It starts at the top.
Must read for front-end developers. No, seriously. Don’t, please don’t let the speed at which you write code influence the future maintainability of your code.
I tried to find a couple of quotes from this article, but I think I need this entire section to sum up where I am as a web developer.
Many web developers have “moved on” from a progressive-enhancement-focused practice that designs web content and web experiences in such a way as to ensure that they are available to all people, regardless of personal ability or the browser or device they use.
Indeed, with more and more new developers entering the profession each day, it’s safe to say that many have never even heard of progressive enhancement and accessible, standards-based design.
The trouble with this top-down approach is threefold:
Firstly, many new developers will build powerful portfolios by mastering tools whose functioning and implications they may not fully understand. Their work may be inaccessible to people and devices, and they may not know it—or know how to go under the hood and fix it. (It may also be slow and bloated, and they may not know how to fix that either.) The impressive portfolios of these builders of inaccessible sites will get them hired and promoted to positions of power, where they train other developers to use frameworks to build impressive but inaccessible sites.
Only developers who understand and value accessibility, and can write their own code, will bother learning the equally exciting, equally edgy, equally new standards (like CSS Grid Layout) that enable us to design lean, accessible, forward-compatible, future-friendly web experiences. Fewer and fewer will do so.
Thirdly, and as a result of the first and second points, more and more web experiences every day are being created that are simply not accessible to people with disabilities (or with the “wrong” phone or browser or device), and this will increase as standards-focused professionals retire or are phased out of the work force, superseded by frameworkistas.
We fought this fight for a reason and it matters today more than ever. Tomorrow is Blue Beanie Day. I’m old enough to remember why. I will be wearing one to stand for accessibility and progressive enhancement. I hope you do too.
Development shops are relying on the communications team at a finance agency to know that they should request their code be optimized for performance or accessibility. I’m going to go out on a limb here and say that shouldn’t be the client’s job. We’re the experts; we understand web strategy and best practices—and it’s time we act like it. It’s time for us to stop talking about each of these principles in a blue-sky way and start implementing them as our core practices. Every time. By default.
A List Apart
I’ve been in the web industry for 15 years, grew into my own during the web standards revolution, and have a huge heart for a11y issues. Seeing our industry revert to, in many ways, the methods and practices from before the standards movement is disheartening at best. We need, now and always, to insist on core development principles.
Here is another great article on web development on the iPad. This stood out to me as I had the same thing occur the other day:
Not all is rosebuds and blue skies though, as Coda has quite a few issues that make it less than ideal for all circumstances. First, the app is very prone to crashing. I’ve had quite a few crashes that I just can’t explain. The app will simply stop responding at random points while I’m typing and not respond until I force quit and restart the app.
I built the website for Ergo Web Tools in Coda after designing it in Graphic. Every once in a while the app would lock up while I was typing and never catch up. I’d have to force quit the app and relaunch it. What’s nice is that Coda remembers your place in a “site” when you come back, but the bad news is if you were running any process in a Terminal tab, it doesn’t restart.
I develop on a Digital Ocean droplet where I have Sass, Grunt, and more tools installed for easy access. So I have to, when Coda decides to lock up, restart my “sass --watch” command. When this happens a dozen times over a couple hours of coding, it is rather frustrating.
Over the next week I’ll likely be sharing a bit more of my design/dev process and some requests that I’d have for the developers behind the apps I’ve been using. iOS has made huge strides over the last few years and doing “real work” is becoming even more plausable.
At some point, the difference vanishes. Most people never did “real work”, by whatever metric, on their computer; they were happy to browse web pages, send emails, Skype friends, whatever. Yet the redoubt of “real work” is defended valiantly, perhaps by those whose jobs depend not on the work, but on the tools used for it – the PC. It’s very notable how often those defending the “real work” divide are also systems administrators of some sort. It’s as if, like the London cabbie, they felt their employment was in peril, while everyone else adapts around them.
So what is a front-end web developer to do? Before Thanksgiving I started doing a lot of research and over Thanksgiving weekend (which was nice and extended for me) I started to build something special.
Building websites on the iPad, even an iPad mini like mine, is a joy when you have the right tools. So I am working to bring desktop-level tools to the iPad to remove excuses. As Twitter says, it’s the #yearofticci.
Web Tools launched today and can be had for a $5.99 introductory price. Head over to the App Store andbuy a copy!
On Saturday I took a trip to Best Buy to play with the iPad Pro. And that sent me on a research trip over the weekend to see if it could replace my current setup. Right now I have a MacBook Air and a iPad mini. The MacBook is used for development and design work and the iPad is used for everything else. Unfortunately, the iPad Pro is way too large and awkward for use in bed, so I feel I would need to keep the iPad mini for that. And, so far, the “pro” software for iPad isn’t good enough to fully replace my Mac needs.
Here is how I see my uses:
- MacBook Air: iOS Dev/Photoshop
- iPad Pro: web dev/general
- iPad mini: reading
Where design apps lack on iOS is slicing and outputting graphics, something required for development. If Pixelmator or Graphic allowed you to quickly slice and output images on iOS, I wouldn’t need a Mac for that.
Beyond that, I need Xcode for iOS. There is Dringend, but it requires a remote Mac to compile and it cannot open Storyboards/XIBs. Some of my projects are Storyboard/XIB free, but not all.
I would love to be able to replace my Mac with an iPad Pro, but unfortunately I cannot yet. I can use an iPad Pro for a lot of what I do, though. So I am considering one.
Virtual hosts are such a great tool for web developers to test locally without losing their mind, but web development in 2015 involves testing on far more than a single machine. If your mobile iOS devices are on the same network, here is a simple trick.
- Go to System Preferences on your Mac.
- Go to the Network panel.
- You should see your IP address in here. Mine right now is 10.0.1.6.
- Go to Settings on your iOS device.
- Go to the Wi-Fi section.
- Tap the info icon on your current Wi-Fi network.
- Scroll down to the HTTP Proxy and tap Manual.
- Enter the IP address you found above into the Server field.
- Enter 80 into the Port field.
- Go to your browser of choice on the iOS device and go to your virtual host.
Simple enough for quickly testing your websites.