I Am Finley

Web Development

DirecTV Will Only Support Internet Explorer Come July

0 Comments

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.

I remember when I got my first Mac back in 2004. Many sites still only supported Internet Explorer 6. And IE6 didn’t exist on Mac. Only IE5 did. Off the top of my head, the biggest two sites that I frequented that did this were my bank and Old Navy. Yes, Old Navy, an ecommerce site, in 2004 only supported IE6. No reason for it, as they didn’t use much DHTML— the hip term for JavaScript at the time— and certainly had no features that would require a specific browser, but that was the way things were done in the early 2000’s. You picked one or two browsers to support and that was it.

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.

But now, so many sites are built to require JavaScript. React, Angular, Vue, and other JavaScript frameworks have taken over front-end development. We are including so much JavaScript on our sites that we need task management scripts and package managers to keep everything straight. Our engineering has gotten more complex than ever necessary.

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.

Permalink

Using a framework is not always bad

0 Comments

Using a framework is not always bad, outsourcing your understanding of the basic languages of front-end development to one is definitely bad.

Rachel Andrew

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.

All too often I see “JavaScript” developers that cannot write a single line of vanilla JavaScript. Front-end developers that struggle outside of Bootstrap. That don’t know what the browser is capable of without Angular.

Have you outsourced your understanding of the basic languages to a framework?

Permalink

The Importance of Personal Websites

0 Comments

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.

Rachel Andrew

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.

Permalink

KISS My Classname

0 Comments

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.

Permalink

Blue Beanie Day and Why It Matters Now More Than Ever #a11y

0 Comments

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.

For many developers—newcomer and seasoned pro alike—web development is about chasing the edge. The exciting stuff is mainly being done on frameworks that not only use, but in many cases actually require JavaScript.

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.

Secondly, since companies rely on their senior developers to tell them what kinds of digital experiences to create, as the web-standards-based approach fades from memory, and frameworks eat the universe, more and more organizations will be advised by framework- and Javascript-oriented developers.

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.

Zeldman

I’ve personally been building websites since 2001. The web standards movement was just beginning. In 2004, I was part of a state web development competition through my high school and they required our sites be built in XHTML and CSS. I felt the push back against ugly, inaccessible plugins— like Flash— and bad JavaScript practices from the start. Fast forward seven years and I led the charge for responsive web design at a Chicago-based agency, declaring that we shouldn’t upcharge our clients for something that is absolutely necessary. That was before we reached 50/50 desktop-to-mobile traffic.

Progressively enhanced, responsive, and accessible websites are in my blood. And that’s why it pains me so much to be rehashing conversations from the start of the standards movement as to why we shouldn’t require JavaScript, or assume that our user’s device supports fill-in-the-blank, or even assume our users can see like we do. And I’m having to rehash these conversations regularly with the Angular and React JavaScript 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.

Permalink

Core Development Principles

0 Comments

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.

Permalink

Using the iPad for Web Development

0 Comments

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.

Permalink

“Real Work” and iPad

0 Comments

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.

For myself, I ask “What do I need to be able to do my job?” LAMP environment? I set up a Digital Ocean droplet that I can SSH/SFTP into. Sass and Grunt? All set up on the droplet. FTP client and code editor? Coda for iPad is fantastic. But I’m a front-end developer, so the browser is a key tool in my toolbox. I need a web inspector to see what styles are applied to an element. I need a way to test responsive websites across many sizes. I need a JavaScript console to look for errors and help with debugging. There are a few apps for viewing the source of a page, but that doesn’t quite scratch my itch. There are a few apps with a simple console, but none of them really work well with the iPad’s big screen. They all seem built for iPhone and enbiggened for iPad.

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.

I call it Web Tools. Keep it simple, right? To start (1.0), Web Tools has a scalable web view that allows you to test any width you want and a web inspector to allow you to easily drill down through the DOM tree and see what styles are applied to each element. And this is just the start. More great features are coming to Web Tools in the coming months, including a powerful JavaScript console.

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!

Permalink

iPad Pro and Me

0 Comments

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:

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.

Permalink

Virtual Hosts and Mobile Development

0 Comments

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.

  1. Go to System Preferences on your Mac.
  2. Go to the Network panel.
  3. You should see your IP address in here. Mine right now is 10.0.1.6.
  4. Go to Settings on your iOS device.
  5. Go to the Wi-Fi section.
  6. Tap the info icon on your current Wi-Fi network.
  7. Scroll down to the HTTP Proxy and tap Manual.
  8. Enter the IP address you found above into the Server field.
  9. Enter 80 into the Port field.
  10. Go to your browser of choice on the iOS device and go to your virtual host.

Simple enough for quickly testing your websites.

Permalink