Native mobile apps are a temporary solution. We’re just over 4 years into the Appstore era and this has already become apparent. Open web technologies are catching up to the point that the vast majority of web apps no longer need a native counterpart.
Don’t try to tell me native apps are faster or allude to them having a “better experience.” That simply is no longer true.
Jim’s argument might be a tad simplistic, but I agree with his points. We’re getting glutted with so many unnecessary native apps that should just be well thought out, responsive web apps.
I’ve been a big fan of Safari for a while; generally it’s my browser of choice in my free time. But for work, I never found it came close to the quality of Chrome, almost entirely due to its poor web inspector.
With Safari 7 out the door as part of OS X 10.9, things are very different. Safari took a huge step forward with their inspector; it’s the first that I’ve used for more than a few minutes without immediately closing the page in question and switching to Chrome Dev Tools. This post details all the changes, the most notable being CodeMirror, an all in one solution for making permanent CSS and JS edits right in Safari. Cool.
Designer Jessica Enders, writing for A List Apart:
The problem is that in the push for simplicity, flat UIs may have gone too far. With content, things like drop shadows, gradients, and borders may well be no more than useless “embellishments.” When we read a multi-page news article, it doesn’t matter much whether the mechanism to move to the next page is a button or a link. With forms, however, distinguishing between a button and a link matters far more.
A thesis that argues for more visual contrast than average for forms may sound a bit simplistic. But it’s not; Jessica goes into some really excellent design examples to show how just a tiny bit more distinction or hierarchy can have significant form conversion effects.
I’m already a huge fan of Scott Jehl’s picturefill responsive images technique. It’s a simple javascript based polyfill that adds the proposed picture element to your site. I’ve used it repeatedly on my professional work and side projects.
But I noticed one important limitation of the base work; because it’s JS powered, there’s a brief moment where the pseudo picture element “pops into” the layout after the initial load. For some pages that effect is acceptable, but for my latest work, I needed more control on when the picturefill effect is activated.
That’s where this fork by developer Tyson Matanich was very helpful. It’s a simple but powerful idea: add an extra method to activate the picture element early before a full DOM load. However I found the rest of the extra options and functionality too much for what my project needed; instead I took the basic gist and forked my own copy of Jehl’s original for actual usage. Works great.
Web developer Louis Lazaris takes a novel approach to extended CSS instruction: spend $7 in the form of an e-book and get 83 solid CSS articles from Impressive Webs. No extra promos, no extra advertising. Smart.
I’m a fan of Dan Mall’s design work, but he rarely comments on more tech heavy issues like web performance. Yet that’s exactly his focus on his latest blog post where he talks through the impact of a responsive design refresh. It’s not exactly scientific; Dan mostly is refreshing Firebug a few times to get his numbers, but I appreciated the approach and the thought process. It’s an encouraging read for performance novices.
I’ve read my share of CSS Flexbox tutorials and feature sites, but none that had the finesse and clarity that developer Philip Walton pulls off here.
I mostly have confined my Flexbox work to just smaller side projects or Chrome packaged apps, given the specifications limited compatibility among all modern browsers (Safari has a bit of catching up to do with Chrome but we’re almost there.) But damn do the showcase examples here make it tempting for future implementation. Even with fallbacks, the code here is just so clean and semantic.
Last week at my day job our team released a newly refreshed Pocket for web. (If you’re at all curious why my blog posts stopped dead midweek, it’s because my life has been fixated on launch and support issues. Thankfully there we few.) It’s been my main development and design focus for months. There’s a simplified navigation, recut reader view, keyboard shortcuts, and everything is noticeably faster. If you’re already a fan of save for later services, or you’re curious but never jumped in before, I’d encourage you to check it out.
With my current job I’m on a very small web team, with little delineation between developer, designer and QA. When you’re banging out code for an impending web release, it’s an environment that can be ripe for regression errors if you’re not careful.
Traditionally one of the best ways to combat regressions are with unit tests (ask any Rails developer.) But for front end developers and designers, there’s often limitations. Sure, you might get valid data from the back end, but how does it actually look and feel? That’s why so many of us rely on lots of repetitive, by hand testing.
Enter CasperJS, a framework perfect for front end unit testing. With a single Unix command running in the background a “headless” Webkit browser that runs through several core actions on my web app, taking screenshots along the way. As long as it stays updated, it’s a great way to check the basics before making any big commit. Great syntax and documentation too. If you’re a front end developer or QA, take a look.