This one-day conference was organised by the super-awesome folks from Web Directions and was described as “a festival of Responsive Web Design for designers and developers of the multi-device Web”. It featured a number of prominent folks from the RWD community from Australia and overseas, including Ethan Marcotte and Jason Grigsby.
Even though I have a vast experience with RWD, I felt like somewhat of an imposter. It had been a while since I had hacked against media queries, fumbled with grids, or dabbled with responsive images. Compounding this problem was the fact that this was my first time attending a conference dedicated entirely to RWD.
Despite all of this, I felt right at home at this conference. The speakers did an amazing job bringing folks along with the materials and concepts presented. Furthermore, I learned quite a number of new things along the way.
One of my favourite presentations was by Jason Grigsby who spoke about responsive mobile-first design.
I think Jason provided a lot of solid advice when it comes to tackling responsive mobile-first design. Of particular interest to me was his insights on the state of responsive images. Of the many solutions available, I found Picturefill - a polyfill for the picture element - to be the most practical for helping to address responsive images.
Polyfills: is there anything thing they can't do?
A little later in the day, John Allsopp delivered a presentation entitled, Well, How Did We Get Here? which I found particularly interesting. John invoked nostalgia by taking the audience on a trip through the world of Web development in the 1990s. I remember those days quite well. So many hacks.
John's presentation was excellent because it provided some context around the theme of the day; responsive web design.
I will admit that I started to feel bad for John after 20 minutes into his presentation. He's seen far too many things in the Web development days of old. Naturally, this prompted me to quip the following on Twitter:
Rounding out the day was Ethen Marcotte's presentation entitled, The Map and The Territory. He delivered an interesting presentation that talked about RWD and the future challenges we face globally as more and more third-world countries come online.
All in all, I had a great time at Respond 2014. I learned a great deal and would be very tempted to attend the conference if held next year!
In the world of web development, there are many roles involved. They include front-end developers, database administrators, testers, framework writers, those folks in DevOps, accessibility folks... the list goes on and on.
One trend I've noticed is for developers to specifically identify as a "front-end web developer". My experience tells me that the world of web development is more than just that. In fact, I find it odd to see developers differentiating themselves on which side of the fence they sit on; those on the front-end and those behind the firewall (or in the cloud).
I bring this up because in order to be a successful web developer, you have to know what is going on in the back-end. Treating the edge of your browser like the Gates of Mordor serves you no good. There's simply too much going on behind-the-scenes that you need to be aware of.
Which brings us to our tools.
Today, web developers have all sorts of tools at their disposal, from integrated tools inside the browser to trace inspectors that allow you to watch what is hitting the wire. At the risk of sounding like a grizzled, old man: these days, the web development kids have it pretty good. Back in when I was cutting my teeth on angle brackets and Java applets, we didn't even have the console object to log to! We had alerts and we loved them, dammit!
Coming back to reality.
As I stated before, in order to be successful as a web developer today, you've got to know what's happening on the server. The problem is that most of our tools still treat the divide between the browser and back-end as a boundary that few should have to cross.
Glimpse is a tool that bridges the gap between knowing what's happening on the client-side with knowing what's happening on the back-end. It runs inside the context of your browsers. There are no tools to install, only a minor installation and configuration change to your server.
Once installed, Glimpse will run at the bottom of your page. New to Glimpse is a supremely-awesome HUD view that gives you the most important information that developers need when clicking through their web applications:
(Image shamelessly stolen from the Glimpse homepage blog. Sorry, guys!)
Anyway, there are numerous tabs that ship with Glimpse. One of the cooler ones is the SQL tab which shows you the actual T-SQL statements that execute against your databse.
It's insanely cool.
Glimpse provides boat-loads of information to better understand your server's configuration, HTTP-related "intrinsics" (like what the server actually saw as the request and what it actually sent as the response), and a whole bunch more. It's particularly useful for developers targeting ASP.NET, as it provides diagnostic information into the ASP.NET runtime, including route resolution. This includes insights for ASP.NET MVC too. And, as I stated earlier, if you're doing anything against a database via ADO.NET, Glimpse can offer insights into the T-SQL that's between executed against your database. You can think of it like having SQL Profiler inside your browser.
In short, Glimpse is a must-have diagnostic tool for web developers wanting to learn more about what's happening on the server.
My reaction after installing Glimpse and gaining insights into what's happening on the back-end:
So, what's next? That's easy. Head to the Glimpse homepage, download the bits via NuGet, and start poking around.
In the meantime, I'll be working on a plugin for Glimpse that I'm working on. More on this later...
Greetings from Melbourne! This week, I attended YOW! 2011, a conference for Australian developers featuring talks on web development, infrastructure and coding practices.
According to the YOW! conference organizers, approximately 500 people registered for this event. This wasn’t a surprise to me; Melbourne has a fantastic developer community and has always supported events such as these. Mitch Denny and I were witness to this when we co-founded the Melbourne .NET User Group back-in-the-day.
After Kasper’s presentation, it felt like my brain had been through the spin cycle of a washing machine. This is a good thing. Many presentations today are way too shallow. I always prefer to “go deep” on something, struggle along the way, and then reformulate afterward.
Anyway, I found a video up on Vimeo of a talk Kasper gave about the V8 engine:
A few months ago, I delivered a presentation at Make Web Not War entitled, “An Intro to HTML5 Canvas”. The purpose of this presentation was to provide folks with a primer on this new element, which allows web developers to draw directly to the 2D context that it provides.
Earlier today, we unveiled IE10 Platform Preview 2, which you can download from the IE Test Drive site.
IE10 PP2 has got a boat-load of web developer goodness and I wanted to this this opportunity to go through some of the “what’s new” and give you my thoughts and opinions on its capabilities.
Please note that IE10 PP2 is not a fully-featured browser; it’s just the rendering engine to give web developers, designers, and enthusiasts an advanced look at what’s to come. It’s not intended to be your default browser so please keep that in mind when downloading and installing the latest bits.
So, what’s new in IE10 PP2? Well, here’s the high-level rundown:
Obviously, as a web developer, there’s a lot to like in this release. However, there are a number of new capabilities in IE10 PP2 that warrant considerable attention. Specifically, support for (1) HTML5 aspects like drag-and-drop, File Reader API, forms, and Web Workers and (2) web performance APIs like requestAnimationFrame and Page Visibility API. Both are important because they enable web developers to target a rich set of functionality to target a specific set of application scenarios and requirements.
New HTML5 Support in IE10 PP2
I was pleasantly surprised when I first reviewed the list of HTML5 capabilities supported in IE10 PP2. A big-time Internet high five to the IE team. Here’s some of the highlights:
Asynchronous Script Execution
The async attribute for the script element allows the associated script to load and execute asynchronously with respect to the rest of the page. That is, the script will load and execute in the background while the page continues to be parsed. For pages using processing-intensive scripts, the async attribute can significantly increase page-load performance.
This is a huge win for web developers with pages that use some gnarly scripts. And, let’s face it: sometimes, these situations are not avoidable. Very happy to see this added to IE10 PP2.
HTML5 Drag-and-Drop (DnD)
Drag-and-drop (DnD) is something that users have come to take for granted as “just working.” Internet Explorer 9 and earlier versions of Internet Explorer supports the dataTransfer object and events to drag images, links, and text. Internet Explorer Platform Preview adds the draggable attribute to any element, and drag-and-drop support for one or more files from the desktop to a webpage.
Of course, drag-and-drop is something that’s achievable through frameworks like Dojo, jQuery and others. However, having it baked into the HTML5 specification and supported is really nice. IE10 PP2 adds support for this and offers an interactivity model that – when combined with other capabilities like File API – allows web applications to behave more like native applications.
Here’s a quick video that the IE team recorded for Channel 9 that demonstrates this capability:
File Reader API
As I indicated earlier, many of the capabilities of HTML5 enable developers to build web applications to behave more like native applications. File API certainly falls within that classification as well.
Internet Explorer Platform Preview introduces support for File API. File API is a W3C draft web specification for representing file objects in web applications, as well as programmatically selecting them and accessing their data. The File API is currently being standardized by the W3C Web Applications Working Group. By using File API, web developers can access local files on the client machine in a secure way without the need of extensions or plugins.
The ability for web developers to work with local files is tremendously powerful, particularly when combined with other capabilities like drag-and-drop and XMLHttpRequest. Collectively, they form the basis of applications that can run entirely in the browser. Incidentally, File API also eliminates the need for plug-ins or extensions that facilitate (multiple) file uploads or the post-submit inspect/manipulation of form data.
HTML5 Form and Input Validation
Internet Explorer Platform Preview adds support for new HTML5 input types and attributes. This support enables developers to quickly and easily provide user prompting and input validation with a minimal amount of script. Before the HTML5 input types and attributes were available, checking that a phone number doesn’t contain alpha characters, or verifying that a properly formed email address has been entered required that the developer write extra logic for validation. Support for HTML5 client-side form and input validation allows the developer to concentrate on other tasks instead of building validation functions.
HTML5 form and input validation is nice. And, in the similar respect to drag-and-drop, it’s something that’s possible to support through various frameworks. However, having it supported within the browser gives us a win around dependencies and (indirectly) overall performance. It reduces – or in some cases – eliminates the need for these frameworks that perform client-side validation and styling, which, in turn, can improve overall performance by eliminating the round-trip to the server that’s necessary to pull these resources down. Validation is another important aspect that’s worth mentioning:
Tooltips like these ones are integrated as part of the overall experience through HTML5 form and input validation and offer up a level of consistency across the sites that utilize them. They can also be used to help validate entries:
Again, very nice and a super-useful capability for web developers building HTML5 applications and sites.
Internet Explorer Platform Preview supports the sandbox attribute, which enables security restrictions for iframe elements that contain untrusted content. These restrictions enhance security by preventing untrusted content from performing actions that can lead to potentially malicious behavior.
More goodness. Now, I will admit that it’s an extremely rare occurrence for me to use iframes. However, I like that this attribute provides an extra layer of protection from potential attack vectors like script injection.
Internet Explorer Platform Preview introduces support for Web Workers. The Web Workers API defines a way to run scripts in the background.
Web Workers are da bomb. Essentially, they establish threading within the scripting context of the browser. That is, the ability to execute processing-intensive scripts in the background. One of the immediate benefits of Web Workers is to offload these computations so that, for example, the user interface may continue to respond to user-generated events like mouse clicks.
Traditionally, browsers have been single-threaded, forcing all the script in your application to run together in a single UI thread. Although you can create the illusion of several things happening at once by using DOM events and the setTimeout API, it takes only one computationally intensive task to bring the user experience to a screeching halt.
The Web Worker API provides a way for web application authors to spawn background scripts that run in parallel with the main page. You can spawn several threads at a time to use for long-running tasks. A new Worker object requires a .js file, which is included via an asynchronous request to the server.
Here’s an example of Web Workers at-work in IE10 PP2:
Whew! Lots of awesomeness! And that doesn’t even cover everything! Just the new HTML5 goodness. Why not download it yourself and check it out?
Hours after its launch, I asked Michael if I could help out. Reason being, over the past number of years, I’ve used a number of tools and found a lot of awesome examples. The problem? I didn’t have a great place to share them with others. Enter Make Awesome Web.
Since its inception just six months ago, we’ve posted 200 awesome resources (including examples and sites) that should help and inspire you to build great web experiences. The response from the web developer community has been pretty incredible. For example, the site experienced over 16,000 views in the month of June alone. Going forward, the plan is to continue posting examples, sites and tools that champion web developer awesomeness. If there’s a resource that’s missing, please let me know! Also, don’t forget to subscribe to the RSS feed if you prefer getting these posts through a reader.
Debugging mobile web apps can be challenging for a couple of main reasons: (1) the screen size makes it difficult to integrate rich developer tools without killing the interface and (2) the tools are somewhat lacking. Recent developments with WebKit (for example) makes this a little easier. However, for the most part, it’s still challenging, especially when you’re trying to test on devices or through emulators. That’s why utilities like jsConsole exist. For those of you who haven’t heard about jsConsole or the man behind the tool – Remy Sharp (@rem) – then I suggest you check out the following video of him demonstrating this utility:
As with all tools/utilities, a word of warning from Remy:
Note that this technique is also injecting code directly in to your web app - this tool should only be used for debugging. I can’t take respibility for how you use this tool, basically: take care!
I tried jsConsole out earlier today with IE9 in the emulator for Windows Phone Mango and I’m happy to report that (1) it works and (2) it works quite well!
For what it’s worth, when things work this easily, my reaction can be best summed up by the following photo:
By the way, you can grab the (free) developer tools for Windows Phone Mango – which includes the emulator – from create.msdn.com. Ideally, this should be your homepage but if it’s not, bookmark it. And, if you targeting a mobile web browser and you’re looking to do a little debugging, check out jsConsole. Awesome stuff.