Maybe one day the Web will be perfect and complete and I will not need to reach for polyfills. However, if that happened I think I’d stop being interested the Web because it would then be a stagnant pond and not a surfable ocean.
Dave brings up that as web developers, we’re quick to complain that that shiny new feature doesn’t have enough support to rely on it and that there should be some sort of global consensus or priority of features so that the most important new features are added to browsers and make all our lives easier. That quote at the end hits the nail on the head though, if it were easy and uniform, then we’d collectively get bored. We thrive on solving problems so much it seems we’ve created more problems.
Great read if you haven’t yet read it yet:
Frank Chimero : What screens want : http://frankchimero.com/what-screens-want/
web and interaction design are just as much children of filmmaking as they are of graphic design. Maybe even more so. After all, we both work on screens, and manage time, movement, and most importantly, change.
So what does all of this mean? I think the grain of screens has been there since the beginning. It’s not tied to an aesthetic. Screens don’t care what the horses look like. They just want them to move. They want the horses to change.
Designing for screens is managing that change. To put a finer head on it, the grain of screens is something I call flux—
and more
Movement, change, and animation are a lot more than ways to delight users: they are a functional method for design.
These examples are essentially animated wireframes, but extra detail isn’t needed. Designing how things change and move is enough for us to understand what they are and the relationships between them. You don’t need the heavy-handed metaphor, because the information is baked into the element’s behavior, not its aesthetics.
A designer’s work is not only about how the things look, but also their behaviors in response to interaction, and the adjustments they make between their fixed states. In fact, designing the way elements adapt and morph in the in-between moments is half of your work as a designer. You’re crafting the interstitials.
We’ve been more aware of this interstitial work in the past few years because of responsive design’s popularity and its resistance to fixed states. It’s a step in the right direction, but it has made work crazy frustrating.
Please read the full article: http://frankchimero.com/what-screens-want/
I needed to write this up about going responsive in response after reading Where to Start (by Trent Walton of Paravel) about getting started with responsive web design. Thanks for sharing your thoughts Trent, I agree whole heartedly. In my experience it is the same. I wanted to share his post and also add my commentary for the parts that I really think Trent is spot on. Some dynamite points.
Longer On-Ramps Have Benefits
I believe Trent is talking about the on-ramp of beginning to create responsive sites. But when I first read the headline about the benefits of a lengthy on-ramp I was thinking about the ‘pre-design’ work that goes into a website. All that work that comes before design and has always been super beneficial to proceed thoughtfully with content strategies, sketching, architecture, wireframes and prototypes. This ‘on-ramp’ stage is even more important in RWD. The time well spent upfront before getting into designs and especially programming really really pays off. Think through all scenarios and purposes and requirements of the site before you hit the ground running. Or else you may get to the finish line realizing you forgot the baton. This is so important concerning responsive from the beginning, when making wireframes for example, we really must think about the available space to render the content.
Design
It’s no longer for prescribing exactly what a site should look like. Instead, it’s used for quick layout exploration and asset creation. As for which view/layout size one should start with, I don’t think it matters. Remember, a single photoshop comp will only express a sliver of the layout potential a fully-flexible responsive site has. It’s impossible to accurately assess a responsive layout in .JPG form.
Yes! Agencies (and clients alike, but I feel that the agencies and developers need to lead the way) need to move past the relic ideal of pixel perfect websites. Not that they should look bad, but they should not all look the same. The nature of the web is to be flexible, right? Let’s embrace progressive enhancements and move on when old browsers don’t see it as nice as current browsers.
CSS
All my values are relative (em, rem, etc.) and based on the 100% 16px base, so I can move code around without losing proportion.
Yes, Again! We need to be relative and fluid all the time. We’ve all picked up some bad habits along the way, but RWD can be seen as a good excuse to remove these.
Breakpoints should always be dictated by our content. Not by `insert popular device of the day`. We should be starting to learn that we shouldn’t rely on any specific device or measurement, because they change all the time. Let’s FORGET device resolutions at the media query stage. These dimensions should be thought out earlier and influence our content strategy. Nothing wrong with using 480 as a breakpoint if it makes sense for your content, but don’t force a square peg into a circle hole. Who knows, next year all these circle holes may become triangles (or spheres) and then we’re stuck shoehorning the square we started with again or starting over. Weird analogy, but I’m just going to let it be.
Regarding Grids, I agree here too. It seems that when using a grid for Responsive Web Design I feel constrained to the grid more than I should. Plus I think it takes the fun out of the process of laying out the content as prescribed. I love the idea of ‘content coreography’ too. It really adds to the sense the required craftsmanship by the developers/designers behind the site well done RWD. It also makes me think of site creators as the directors who layout and present data and lead the story telling of the site.
I’ve said it before, but I’m constantly excited by the web design industry because as it is such a young field, we are still making up the rules and discovering as a community what processes are best. At the same time, the technology driving the field is changing so fast that just when we start to settle into a routine it all gets flipped on it’s head and we’re reconsidering everything again.
Please read Trent’s full article as I’m sure it’s packed with good nuggets for you too.
When making the transition to building responsive websites, the hardest part can be getting started.
I get my fair share of questions about how to choose a direction and chart out the first few steps from industry comrades and potential clients. It can seem daunting, so I thought I’d attempt to sum up a few of my own current thoughts on the matter.
Great points about apps and the web in this article.
Apps compete with the web for dominance over where people get their content. Apps as games and tools are perfect, but apps for content are not. Content is best on the web, because the web is built for sharing content. The web is open! The web is consolidated and instant and accessible (meaning that any device/browser/screen size/location/etc can already access the web and you can update it anytime and all users see the update instantaneously). The web is also accessible via the defining url. Meaning that it’s a required standard that all assets and bits of content have an address. You can take this address and share it and return to it easily, apps – not so much. You want to share an experience or idea from an app with a friend (sure, some have a process built in), you first check to see if their device has this app available, they want to go through the steps of finding the app and then installing it (likely having to pay money) and then you send them a link have to explain how to get to where the magic happened.
Newfangled, a web agency I respect for being very smart has a great article about this. It was then moved into the basis for a chapter in their ‘The Strategic Web Designer’ Book. I highly recommend them both!
Recently, I stumbled on this tool that has really helped my development process. It keeps my css file(s) current in the browser as I edit and save them. Before this I’d make an edit, save/upload (which I’ve combined into one step with SublimeText) then switch to the browser and refresh the page and/or clear cache to make sure the latest edits are loaded. Then rinse and repeat. But now with this tool I’m able to save my edit and glance at my browser as it auto refreshes the stylesheet once it notices the new file (usually about 1 second) and I see my edit, and continue with my edits. It may seem small but after doing this dozens and perhaps hundreds of times each day you can understand the simplicity of this!
[Before I used a javascript based tool called CSSRefresh which would just automatically reload the css file every second. Which had the same effect, but was a heavy consuming load on the browser as well as on the server. It ended up making the browser go much slower (especially when scrolling) and it crashed it often. Sadly, I was forced to accept the tool as a flop for my workflow.]
SoFresh is a bookmarklet based tool though. It allows you to specify a css file or more to ‘watch’ and then when the file changes on the server it smartly reloads it, saving me the trouble to switch apps reload page and wait and potentially reload while clearing my cache. My refresh and cache shortcut keys are much happier now and I take a breath every time I save an edit.
Here’s a great “HTML5 Love Story” about the team at Sencha, who is passionate about using proper technologies for the one open web, who knew better than to trust that the failure of Facebook to create a reliable HTML5 app for users was because HTML5 wasn’t ready (as Facebook claimed). They built this demo to prove that HTML5 can do all that the now gone native FB app does and faster. The trick is you have to know what you are doing. Something it seems, FB doesn’t. Ready the full story and watch the comparison video: The Making of Fastbook: An HTML5 Love Story | Blog | Sencha. Or go try it yourself. Visit http://fb.html5isready.com on your favorite mobile browser.
When we started what became Sencha, we made a bet on the web: a bet that modern application development didn’t need anything except the browser, a great set of frameworks and a great set of tools. With those three weapons in hand, we knew developers could build applications that would delight users. The advent of HTML5 upped the game and it gave developers even more tools to let them treat the browser as an application development platform and not a page rendering engine. Developers sprang at the opportunity and unleashed a torrent of apps — on both desktop and mobile — that leveraged the new HTML5 capabilities to build amazing applications using web standards.
So, when Mark Zuckerberg said HTML5 wasn’t ready, we took a little offense to the comment.
We thought to ourselves: HTML5 can’t really be the reason that Facebook’s mobile application was slow. We knew what the browser on modern smart phones was capable of and what kind of rich capabilities HTML5 offered. We saw the latest generation of mobile devices — running at least iOS 5 or Android 4.1 — push ever increasing performance and HTML5 implementation scores. But perhaps most importantly, we’d seen what our customers were building and the amazing things they were creating using HTML5.
I totally agree with this sentiment and believe that native apps are the new flash to the web. They are fun and seem to be the way, but give it a few years and these native apps will quickly give way to web based apps that are browser based and offer speed and flexibility and consistence to the web experience. Sure, flash can do things that html still can’t. But I’m pretty sure no one would want to build their whole site in flash today. They would put the parts that need to be or the parts that belong in flash in flash and let the rest be standards compliant open web. Facebook has essentially built a flash based website for phones to access their website content. They will have to maintain and update this separate from their “real” version.
Our smart phones are helping us converge our devices, as in we no longer need a phone a camera a gps a notepad a … But it is not helping us converge our internet or content. We currently need to use a website in one way at our desk and another way on the go. Websites and the internet should have the same capabilities and the same uses no matter where we decide to use it. Sencha is showing us that, built correctly, HTML5 truly is ready to handle many things that belong in the browser rather than in a native app. We should never need to download a native app to access website data that we normally would just login at our desk. That’s inefficient, divergent and complicated. It’s against the openness and standards everyone preached and pined for and indeed “won” when flash-haters succeeded in ousting flash from mobile browsers. I actually respect Adobe for finally pulling the plug there because they too, believe in the web (and at the time, I was a full-time flash developer). I believe in the web too and that’s why I call it the one open web.
Jason explains the root of the problem and why no one has been able to devise a solution that makes everyone happy yet. The browsers (in their awesome drive to make browsing faster) are prefetching images and developers want to only use one image based on criteria the browser doesn't know until the layout is calculated.
Echoing some other thoughts and comments I’ve read, but writing it out so I can grasp the details.
What about the updated image format that by default only loads the smallest embedded size. Then once the browser finishes layout and knows what size the image is rendered at (and also resolution) it can update the request for an image that’s embedded in the file that best fits or matches the requirements. This by default would load the smaller part of the file and display something for the prefetching browsers and “enhance” the image as it can. I can see photo editing software like photoshop (if that’s your poison of choice) to have extra settings for creating this new image type – resolutions to include, breakpoints to be set, etc. The we aren’t managing multiple images – it’d be one file that included all the desired sizes. Very much like progressive images and old gifs. Mobile browsers and old fallback browsers would display the smallest (or first) specified img (although this could also be determined in the meta data of the file – which subimg would be the default). This may end up in users with high BW/large screens to download two subimages rather than only the high res image, but remember that the first one would be much smaller in size and if they can handle it the big one the big and smallest together shouldn’t be too heavy. The page would also load very fast as the first image to load would be much faster than loading the large image initially whatever the bandwidth. Then browsers and image compression engineers can get together and figure out a communication method between the browsers and images via metadata and requests while developers/designers can just choose the proper settings as they save the files (or software can have standard-best-practice defaults) and focus on creating websites rather than having to understand how all browsers and devices will load and present content.
Also – Amen to @Brian Gallagher: “Who are we to make the distinction between what the users NEEDS to see, and what the user WANTS to see?”
Embedded Link
» The real conflict behind and @srcset Cloud Four Blog
Some people do a lot of research before they travel. They read guidebooks. They like to know what they are going to do before they get there. Others want to experience the new place and let the serend…
Here are my notes on the presentation from Lee Brimelow of Adobe at the Atlanta Adobe Users Group Meeting: http://www.meetup.com/Adobe-User-Group-of-Atlanta/events/56200162/
What is flash for? Doing things the browser can’t! If you can use HTML5 then do it. Learn about it and learn the capabilities and know when to use what tool and when they are appropriate. It might not be easy, but it is where the industry is moving, don’t hide from it! If you want to do things that are to advanced for the current standards and browsers, then flash is most likely where you need to be. Adobe will always position Flash to be ahead of what is possible with browsers.
While you can do some gaming in browsers today, flash is now positioned to be the best solution for game development. It even can compile to native apps for ios and many successful apps have done so. Adobe has put in a site to showcase these games at: http://gaming.adobe.com
Adobe has a new partnership with unity. See example game: Angry bots.
Console sales are declining. We have so many other outlets to game: browsers, social, mobile devices… Soon professional games will be via Facebook and browsers.
Facebook angry birds game built in flash using stage 3D.
New gaming features:
Mouse lock.
Right and middle click events.
Concurrency, multi threading for player. Yo will not lock up with intense calculations.
Native extension Burls and extensions.
CS6:
Sprite sheet exporter!
Create js exporter, via Grant Skinner
Html 5 export to canvas a vector art.
Edge
11.3 – latest flash player
full screen keyboard input.
Background auto updates.
Audio streaming via net stream.
Improvements for low latency audio.
Stage 3D progressive texture streaming.
Lzma compression sort door byte array.
Native bitmap encoding to png and jpg.
Bitmap data draw with quality
Frame labels.
Air specific
USB debugging for ios
Native ios simulator support
Enhanced background support for ios
Android 4 stylus support
Mac app store support
Dolores, upcoming updates
As workers
Advanced profiling
Better sort for hardware accelerated video cards
Next
Refactorizing code base
Work on as virtual machine
Many action script language updates: stringent static typing as default, hardware oriented numeric types, type inference…
We need more articles like this that talk about process and how they are applying these new web mantras like ‘Mobile First’ and ‘RWD’ and ‘Design in the Browser’. These mantras lead us to think these techniques are very black and white, but there is a lot more to it than that. Like most everything else on the web: it depends.
Basecamp announces that it’s new version will not support old browsers! They will of course continue to support them in their “classic” version. But this is good news and as more implement this type of policy the internet will be happy.
It used to be one of the biggest pains of web development. Juggling different browser versions and wasting endless hours coming up with workarounds and hacks. Thankfully, those troubles are now largely optional for many developers of the web.
I needed to write this up about going responsive in response after reading Where to Start (by Trent Walton of Paravel) about getting started with responsive web design. Thanks for sharing your thoughts Trent, I agree whole heartedly. In my experience it is the same. I wanted to share his post and also add my commentary for the parts that I really think Trent is spot on. Some dynamite points.
Recently, I stumbled on this tool that has really helped my development process. It keeps my css file(s) current in the browser as I edit and save them. Before this I’d make an edit, save/upload (which I’ve combined into one step with SublimeText) then switch to the browser and refresh the page and/or clear cache to make sure the latest edits are loaded. Then rinse and repeat. But now with this tool I’m able to save my edit and glance at my browser as it auto refreshes the stylesheet once it notices the new file (usually about 1 second) and I see my edit, and continue with my edits. It may seem small but after doing this dozens and perhaps hundreds of times each day you can understand the simplicity of this!
