SXSW notes, Tech sessions

Sorry about the long break in my SXSW notes recap. Time sort of got away from me there.

I didn’t go to as many tech meetings this year as last, which was good and bad. I’m glad I got to go to a variety of sessions, but the few tech sessions I attended left me wanting more. This may point out that I need to go to a more tech heavy conference sometime in the future.

The State of Browser Developer Tools

Brandon Satrom, Garann Means, Joe Stagner, Mike Taylor, Paul Irish

The gist of this session was: browser developer tools have come a long way in a short while, and it is worth checking out what each browser has to offer.

Chrome: Offers a new color picker, and some subtle but nice UI changes that makes the dev tools much more useful. You can also save the CSS out to a new file. Both Firefox and chrome have very nice CSS tools in this regard, and if they come just a bit further (some auto completion, better color coding) they could make it so I don’t need to find a replacement for my long in the tooth and no longer made CSS Edit 2.

Chrome for android: Plug in via USB, run the dev tools from the device.

Firefox: When viewing a page, go to Tools -> Web Developer (different from the web developer toolbar) -> Inspect and then click on “3D” in the bottom right. It’s called “Tilt” and it made the room collectively gasp.

Opera: Offers remote device debugging and great emulators.

IE 9 & 10: let you emulate older versions of IE. (I have found this to be a tad off- I’ll use the IE7 emulator and then view the page in IE7 and they’ll be different- but it is pretty close.)

What’s coming:

Adobe Shadow: Multi device checking (Here now, will get better)

Usability for styles. HTML tidy-like features.

CSS for Grown Ups: Maturing Best Practices

Andy Hume

Web standards can become an obsession. We get ridiculous code to keep content and session separate, but managing complexity is important too. Complexity raises the barrier to entry.

We need to optimize for change. Most of all, we need to let go of the idea that we will write HTML which we will never touch again, and do everything on the CSS side. We will ALWAYS have to revamp the HTML along with the CSS.

Bullet points:

• Check out stuff like: OOCSS, SMACSS, CSS Lint – advocating a new set of best practices.
• Should have layers of CSS: Layout styles – Module styles – base styles on top of the HTML
• Come up with classes that describe the presentation. headline, subheadline, byline, etc.
• The important thing is to do what is best for your local situation, and not to hold to outdated dogma for the sake of dogma. You have to strike a balance between performance, maintainability, and readability.
• Use presentational class names and surgical layout helpers.
• Document your code in code, NOT a PDF! Twitter bootstrap is a good example of this.
• Write a complete style guide. Use it consistently for your organization. Include interaction.
• Think in terms of modules, not pages. Have a style module library.

Creating Responsive HTML5 Touch Interfaces

Stephen Woods

Switching to thinking about devices rather than interfaces is hard. Interfaces should feel good in addition to looking good.

Some advice:

• Prioritize user feedback.
• Use hardware acceleration
• manage memory – devices are always low on memory
• Do not load during gestures – hold it till the end
• Treat the DOM as write only, do your own math. “If you just do the math, you’ll be happier in the long run.”
• Use matrix transforms.
• Use CSS transitions. Use transitions with easing to snap back, good enough in most cases.
• Feature detect and add as devices support. Disable things per user agent.
• Simulators and emulators are basically useless.
• Div’s with background images load quicker than embedded images. It’s not semantically correct, but it’s OK.

Frustrating limitations:

• The retina screen is huge, device memory is small
• Hardware acceleration is a crash festival.
• You are always finding devices that want to “optimize” your carefully designed sites.

The Right Tool for the Job: Native or Mobile Web?

Buzz Andersen, Jacob Bijani, Majd Taby, Matthew Delaney, Tom Dale

Software, a brief history: Web browsers ushered in a dramatic abstraction in computing. “The web browser is one of humanities’ greatest achievements.” Javascript is the word’s most popular programming language.

The age of apps: A return to the native, device centric programming we had before. For the first time since netscape, native dev is leading the way. Foursquare/square/instagram -> native first!

Native Cons:

• Networking
• Linking/ cross platform distribution
• Rich text – browsers handle it much better
• Layout
• Caching
• Fast is difficult
• You lose all the “free stuff” you get with browser abstraction
• When dealing with ios, have to deal with apple: “Apple has started asking ‘What’s better for apple’ instead of ‘what’s better for the user.’”
• Multi device is hard
• App stores are horrible places to actually find anything

Native Pros:

• More direct influence
• More primitives are available to you
• Monetization (maybe)
• Access to hardware – may be necessary, depending on app
• Faster when done right
• Good Documentation (sometimes)

Stuff to keep in mind

• Got to rng.io to see your devices capabilities.
• Check out the Financial Times (on your device) for a web HTML5 app that does it right. (Or switch user agent to fake it)
• If you build a hybrid native/mobile app, you have to work extra hard to make sure they stay in sync/don’t contradict each other
• Avoid creating an app just so you can say “we have an iPhone app!”
• Avoid “The uncanny valley of web apps” – don’t try to emulate the native look on mobile apps. Emulating native UI is a moving target and rarely worth it.