Global Nerdy

Click the graphic to contemplate its mysteries at full size.

As a graduate of both Catholic school and a computer science degree program, I have to salute @angealbertini, who created this, with a filet mignon on a flaming sword.

Tampa iOS Meetup (Tuesday, March 27th)

On Tuesday, I’ll be leading the Tampa iOS Meetup group through another exercise building an augmented reality app with ARKit. This time, we’ll build a simple version of IKEA Place, the app that lets you see how furniture in the IKEA catalog would look in the room you’re in.

Tampa iOS Meetups are “code along with me” exercises. I’ll provide you with a starter project, and together, we’ll build a working app. Note that this meetup requires you to bring the following:

• A Mac with the Xcode 9.3 beta installed (you can get it from developer.apple.com)
• An ARKit-ready iPhone (iPhone 6S or later) or iPad (any iPad Pro, or the 2017 iPad) running the iOS 11.3 beta

Tampa iOS Meetup will take place this Tuesday, March 27th at the Sourcetoad office (2701 West Busch Blvd., suite 1018). We’ll provide omnivore and vegetarian pizza and drinks. If you want more details or to register (it’s free), visit our meetup page!

Synapse Innovation Summit (Wednesday, March 28th – Thursday, March 29th

I’ll also be at the Synapse Innovation Summit, which takes over Amalie Arena this Wednesday and Thursday.

With 2,500 attendees catching the following over two days…

• 56 breakout sessions
• 200 speakers (including IBM’s Chief Innovation Officer, a colonel from SOCOM’s Transnational Threats Division, the CEOs of Hyperloop, Connectwise, Bionic Miracle, and Innovation Hub)
• 60 showcases
• 250 exhibitors

…it should be an interesting event.

RWDevCon (Thursday, April 5th – Saturday, April 7th)

Next week, I’m off to the D.C. area to do double speaking duty at RWDevCon, RayWenderlich.com’s annual tutorial conference. RWDevCon 2018 is their 4th annual mostly-tutorials, high stuff-to-fluff ratio conference, and I’ll be there to do both a full-afternoon workshop and basic tutorial on building augmented reality apps for iOS with ARKit.

Along with a number of my Sourcetoad coworkers, I’m taking a couple of hours off to see Apple co-founder Steve Wozniak speak at USF this afternoon. It’s the inaugural event in USF Muma College of Business’ Thought Leader series. It will be moderated by the school’s dean, and promises to feature topics ranging from entrepreneurship to issues with the age of supercomputers in our pockets. Woz and the dean will accept questions submitted via Twitter using the hashtag #USFMumaTLS.

Seats for this event “sold out” (it’s in quotes because tickets were free) so quickly that they had to move it from its original venue at the Muma College of Business to the Sun Dome (USF’s sports arena), and once again, the newly-added seats were snapped up quickly.

I cut my programming teeth on an Apple ][ with AppleSoft BASIC and 6502 assembly language. The first computer I bought as a newly-graduated I’m-a-real-grownup-with-a-job person was an Mac Quadra 660AV, and the first computer I was assigned at my first job was a PowerMac 6100/66 “FrankenMac” (it had a Wintel card in it, so I could switch between Mac and Windows development with a keystroke). Decades later, my work and home machines are both MacBook Pros, and I’m not just cranking out software for Apple platforms, I’m even teaching people how to do the same at meetups and conferences. I come by my Apple sentimentality honestly.

I’m pretty sure that the odds of my being able to get an autograph from Woz are slim, but I’m bringing my original Apple ][ Reference Manual just in case:

Click the photo to see it at full size.

Here’s part two of my notes from the 2-hour talk that npm COO Laurie Voss gave at Tampa Bay Startup Week, Stuff Everybody Knows (except you). Regular readers of this blog will know that when I take notes, I really take notes.

In case you missed part one, it’s here.

What is coding?

• Now that you’ve gotten good at the basics, it’s time to do your job: actual web development.
• Coding is:
  • 50% solving the problem
  • 50% communication — that means listening to the person whose problem you’re trying to solve.
• You have to understand the broader context of and the constraints under which you’re operating.
• You have to recognize priorities.
• Solving in the abstract solves a problem that you’ve invented in your head, but not the problem that you’re being paid to solve.
• Understanding the problem is crucial to being a web developer, as is communicating back your solution.
• Once you written the code, you should be able to explain what it does, what it doesn’t do, where the bugs are, how it’s documented, how to test it.
• If you write code that only you understand, you are its only user, and that’s of no use to anyone.

HTML

• Tim Berners-Lee’s original intent for HTML wasn’t the web as we know it today — he was aiming for something more like Wikipedia.
• He was thinking of a two-way editable database where everyone could share facts and link to them.
• His use of hypertext was an accident, but it turned out to be much more flexible.
• HTML is semantic — it’s not a language about how to display things, but a language about how to represent things and what those things mean.
• The tags in HTML have meanings: this is a list, this is a navbar, this is a link. It says that certain information isn’t just text, but has some meaning.
• The link tag is the best example of why semantic markup is important.
• You can implement links in other ways — e.g. <div> tags with onClick JavaScript that do the same thing — but that’s not actually what we do. We use an anchor tag — the <a> tag — because it says “the text in this tag relates to the web page at this URL”. You’re creating a semantic relationship, which the <div> tag with the JavaScript doesn’t.
• The web is the web because of the <a> tag!

JavaScript

• JavaScript is not a thing that everyone knows or agrees about.
• One important thing about JavaScript: you don’t always need an app.
• People love building rich web applications, but they’re big, take several seconds to load, and often, a web page will be more than enough to do the job.
• Rich web applications:
  • Are harder for search engines to parse
  • Load more slowly, especially on mobile devices
  • Add a lot of things that can go wrong
• The New York Times isn’t a rich application because it would be overkill for what it needs to do: present a news article, leave it onscreen for the minutes you read it, and then go away.
• Think carefully about whether you need to build a web application and bring on all its trade-offs, especially if you’re thinking about mobile users — and you should.
• As of 2015, about half of the web’s experiences happen on phones, whose processors run at speeds slower than laptops. Rich web apps make them even slower.
• You’re probably sacrificing mobile users’ experience because rich web apps are fun to build, but they’re not always the right thing to build.
• The other important things about JavaScript is that you should use it optionally.

• You should consider progressive enhancement. It progressive enhancement used to be popular, then it fell out of style, and it’s back now.
• Progressive enhancement answers the question “What happens is JavaScript is turned off?”.
• It may sound ridiculous until you consider that JavaScript is effectively turned off for the first 3 or 4 seconds while the page loads; it’s the last thing to happen. This is even more true with lots of people browsing on their phones.
• Your rich web application will stop working if it stop loading because your user has gone to a place where the signal is weak, which happens all the time. This won’t happen to the New York Times because it’s not a rich web app!
• Your site should be able to do something useful even when JavaScript hasn’t loaded. You ecommerce site should still display price and quantity even if the JavaScript for the “add to cart” button didn’t load. Your failure case should still be useful — your pages shouldn’t be all or nothing.

User experience (UX)

• Not what it looks like, but what it feels like, and that’s far more important.
• URLs are part of UX.
• HTTP is a stateless protocol, which is a fancy computer science way of saying “No matter who you pass a URL to, if they follow it, they’ll see the same thing”. If both you and I follow the same URL for a terrible article, we will both see the same terrible article.
• This seems obvious to people who’ve been on the web for a while, but it’s unique to the web, and it’s why the web is so popular. It runs off social networking and our deep-seated desire to share stuff with each other.
• If you’re building a web app, you need to think about how people share it. You can’t have a rich web app that has a single URL that is the home page and a bunch of random shit that happens when you click buttons.
• You should be able to follow a path into a site really deeply, and when you find something and want to share it, you should be able to copy its URL, send it to someone, and they should be able to follow it and see the same thing. That’s how the web is supposed to work.
• Support deep links because the web is social and people share stuff.
• Don’t break URLs! And remember, they’ll end up shared and embedded in everything.
• Your URLs from 10 years ago need to work today, otherwise you’ll lose people who are trying to find you.
• Supporting deep links isn’t just good social networking and SEO; it’s also crucial to scaling.

• Beware Twitter’s hashbang mistake, which they made when they tried to turn it into a rich web app.
• At the time — 2010 — they needed IE6 compatibility, and so they decided to make use of the hashbang.
• The problem with the hashbang is that everything after it in the URL is considered to be a page fragment — it means it doesn’t go to the server; it’s handled on the page.
• This decision means that now and forever, Twitter’s homepage has two jobs:
  • It has to be Twitter’s homepage, and
  • it has to be the location of any one of 1.8 billion tweets
• If you load Twitter’s homepage from scratch, you’ll see that it stays blank for a second while it tries to determine if you want to see a homepage or a tweet and if it’s a tweet, has to load the user interface and then dig into the database to get that tweet.
• It’s a 2010 engineering decision that broke everything; they’re stuck with a stupid one-second delay forever because they can’t break all those URLs that have been shared.

Solve the users’ problems, not your problems

• A general principle of UX is that you should solve the users’ problems, not your problems; you should be aiming for usability over impressiveness.
• Landing pages, interesting animations, and shadow effects look great the first time, but by the third time, the thing users remember is the slowness of your site.
• Carousels are a really great example of developers solving their problems rather than the users’.
• For some reason, the people who make web sites were under the impression that users would go and click arrows to view the pictures in the carousel.
• See this article from the UX experts, the Nielsen Norman Group, who point out that not only do people not use carousels, they don’t even know what  they’re for, they don’t know how they work, they don’t know what the little dots at the bottom are for, and so on.
• “Solving” the users’ problems with carousels by making them autorotate just enrages them, because the thing they were just reading disappears.
• The only reason carousels exist at all is because Apple uses them all the time. Apple can get away with it because they have an entire operating system built around carousels; your web page cannot.
• Carousels are there because they solve an argument in the marketing about which picture to put on the home page: “All three pictures are on the home page! It’s fine!”. That’s not the users’ problem.

Be predictable

• Links should go places. You click them, and you go to another web page, where you can click the back button and return to the previous page, and nothing has changed.
  
• Buttons should do things. It changes something — it buys something, or deletes something, or kills someone you love.
  
• You never get angry emails from users saying that you violated their expectations by making a link behave like a button or making a button behave like a link, because most users don’t have a UX vocabulary. Instead, they simply remember that your site behaved annoyingly, leave, and never come back.
• Another way sites behave unpredictably is by using horizontal scrolling. Nobody scrolls horizontally!
• On sites that scroll horizontally, users try in vain to scroll vertically, fail, and leave.
• Remember the principle of spatial memory: our instincts and senses are tuned to the jungle, and thus we have a memory for where things are in space.
• If I’m on a web page and I scroll three feet down the page, I remember that the login button was at the top of the page, three feet up and can find it.
• Developers mess with spatial memory by using JavaScript to make objects on the page shimmer into the background, or float away, or otherwise disappear someplace else, undoing spatial memory, and breaking the sense of where we are on the page.

Be fast

• Performance is invisible UX. It’s an overlooked aspect of UX.
• More than any other thing, the speed at which a page loads determines how good a user feels about it.
• If you have a web page that takes 10 seconds to load because it has a widget, and removing the widget still leaves most of the page useful but cuts the load time down to one second, you should absolutely do that. People like fast pages more than pages widgets on them. This is why Craigslist , with its ugly-ass UI is still popular.
• Fast sites encourage exploration, slow sites encourage abandonment.

Mobile first

• I’ve said this before, but I need to say it again. About half of the time spent on the web is spent on mobile devices. That’s a fact that hasn’t percolated down to the people who design for the web.
• You have to consider mobile first, and design for the case first. Then you can design for the desktop case. Don’t think about designing for the mobile web as responsibly squeezing things down for a small screen, think about the mobile site as they place they’ll go to first.
• The social nature of the web means that we get links to things when we’re walking around, when we’re using our mobile devices. Before we decide that we’re going to look at something on your desktop, we look at it on our phone, and that’s when your first (and likely only) chance to impress the user.

Accessibility is not an option

• Accessibility is not optional. It’s not a thing you later or a thing you add if you’re rich, or if you’re feeling magnanimous.
• Accessibility means accessible to people who view the web in a way different from you.
• 3.4% of web users have limited vision. If you add in people who have motor control difficulties (for whom very small buttons are difficult to use), and people who have cognitive difficulties, the number of people who view the web differently from you rises to a not-insignificant 8.5%.
• If you’re building an ecommerce site and the question you’re asking is “How do we grow our market by 8.5%?” the answer is to make it simpler.
• The answer to accessibility is to do less! Use built-in controls, because browsers, screen readers, and accessibility devices know what they’re for.

Also in this series

• Part 1