On the role of Responsive Web Design

Stuck in the Delta Lounge at JFK on the way back home, can you think of a better time to reflect on DevConnections sessions? As I get ready for reflection, I also feel the need to curse on Alitalia that doesn’t check me in online and requires me to walk through another layer of security to check in face to face on a code-share flight.

At DevConnections I held a workshop on building device-friendly websites and also gave a couple of sessions on the accidental relationships between DDD and Entity Framework and enhanced web input forms. I had a bit of discussion with attendees and other people of the role of RWD in the building of responsive sites. Here’s a summary of my workshop. By the way, the source code is here.

The workshop started with a critical review and analysis of RWD. It ended with attendees sincerely captured by WURFL.js–a free JavaScript endpoint that does transparent device detection and just puts in your DOM an object that tells about name and form-factor of the device, whether desktop browser, smartphone, tablet, smart-tv, watch, bot, or even a webview within a native app. I may seem like a guy who just hates RWD.

No, I just try to fight the blindfolded perspective that RWD is all you need and device detection is nefarious and the clear sign that you’re not doing a good job of designing and architecting your site. At the conference I also attended another talk on RWD and got illuminated when the speaker put an encyclopedic citation of an “expert” saying something along the lines of “we cannot have a single design for each application–we must upgrade to having a single design that works in all cases”.

Gotcha!

It’s that RWD stems from a designer’s–not developer’s–mind and vision. Developers, though, do a different job. Developers SHOULD be ready to focus on use-cases when they emerge out of requirements. Because devices exist and make a point of providing a unique experience, treating them as they’re all the same is against common sense. I grinned then when the speaker with a serious expression admitted that, yes, beyond aforementioned wonders, RWD does have the problem of performance. Really? OMG.

In the end, RWD is an excellent first-aid for setting up responsive sites. If experience is good, performance is good and nobody complains then all is good whether you used Bootstrap for it or your own combination of HTML5+CSS+JS. When you start getting complaints, then fixing RWD may really become expensive. Thinking that RWD can be applied tout-court and those who detect devices are a bunch of idiots who are not as smart as you is a plain distortion of the reality.

My workshop just showed the two faces of the coin. It showed facts and numbers (rather than astonishing demos) and left conclusions to developers.

The Mobile Bubble that Kills and Resuscitates Apps

Taking cue from what my friend Davide Senatore wrote in a recent Facebook post, I want to share my perspective of mobile apps.

Even though I wrote a book on mobile architecture and mobile development jumpstart (iOS, Android, Windows Phone, PhoneGap) I haven’t done much work with mobile apps in the past year or so. I spent a couple of years a way back trying to make sense of the patterns and now I’m mostly acting as an advisor to some companies needing to build a mobile presence and elaborate a mobile strategy. My iOS developer account expired a few weeks ago and so it was for the Windows Phone account. Probably, both will be back some time soon but for the time being that’s it.

Two years ago I made the most significant experience with mobile apps. Two years ago the customer was really excited to have a few mobile apps to support the event. Last year the same customer kind of took it for granted and just looked for paying the update as little as possible; possibly nothing.  Every business has an app that, like web sites of fifteen years ago around the time of the Internet bubble, just do nothing serious.

People are led to think that most apps are just crap put there because of a trend.

As I see it, this means that the mobile bubble is approaching fast if not here already. Much like the Internet bubble didn’t kill the Internet, the mobile bubble won’t certainly kill the mobile. It will just put a few key things in the right business-oriented  perspective and get rid of anything else.

Mobile apps will die soon and some of them will resuscitate  later under another perspective.

Smoke-mirror apps created to let the world know ‘hey we have an app; download it to get a discount’ are all gone. Consumer apps are for the most part gone. Time-sensitive apps bound to events are for the most part gone.

What remains? Well, all of them.

Provided that the apps serve a specific purpose (WhatsApp, Twitter, Uber, Hailo, OneNote, games, a few personal utils apps, …)  or are the frontend of some significant enterprise system.

Don’t waste your time trying to create the next big app at all costs. Don’t expect that just any idea for an app (even good/great ideas) will make it a success or change the way people live and work. Don’t expect people will get it and rate it honestly. The true and sure frontier of mobile is where there’s a promising business case. But in this case the mobile app is merely the presentation layer.

JavaScript browser detection is here

If you’re good at googling you can find a few scripts out there that do the job of detecting the browser connecting to your site. To my knowledge, the best of these scripts can recognize whether it’s an iPhone or an iPad, an Android and little more. In summary, you can easily search for a few keywords and make some reasonable guesses.
Before you start jumping for joy thinking of how easy it could be let me add that knowing that it’s an Android is of not much help. Android what?

As you may know, it’s three years now that I’m part of the team that manages WURFL, the de facto standard of device detection. WURFL is a cross-platform API also available for ASP.NET via Nuget. Up until now, WURFL was only available for server-side detection. You can check my articles on MSDN Magazine for inspiration.

At the Mobile Congress today came the announcement that a client flavor of WURFL is also available for JavaScript. All you do is adding a short script to the page and receive a variable named WURFL that contains some basic information about the requesting device. The backend engine is the same of the cross-platform API. You can trust it 🙂

Here’s what you need to add to your pages:

<script src="http://wurfljs.com/wurfl.js"></script>

and here’s what you receive for Internet Explorer 11.

var WURFL = {
    "complete_device_name" : "generic web browser",
    "is_mobile"            : false,
    "form_factor"          : "Desktop"
};

The property complete_device_name returns the name of the device and it doesn’t go into much details for desktop browsers. The is_mobile property is a Boolean telling whether the agent is a mobile one. In my opinion this property is not much helpful. The real game changer is form_factor which returns string like “Desktop”, “Tablet”, “Smartphone”, “Robot”, “Smart-TV” and “Feature Phone” when it’s just a phone device but not that smart.

I set up a sample page for you to check the API: visit http://www.expoware.org/wurfljs. For more information, visit ScientiaMobile or contact me.

Free Android Course from JetBrains/Tuts+ (and me)

Jumping to the Android bandwagon is not an easy jump and for some reason it seems harder than it actually is. Developing for Android poses a number of additional issues that you nearly never face for other “stricter” platforms such as iOS and Windows Phone. At the same time, I don’t even think that the “freedom” of the Android world is a real benefit for the majority of developers.

Fact is, at some point you may face the need of writing Android apps. When it happens you then need to learn the basics of the programming model as well as the tools and frameworks that are either required or helpful. You may be pleased to know that JetBrains and Tuts+ managed to bring (me to bring) you a FREE (yes, free) course of Android programming just designed for the busy developer.

Busy means you “need” but hardly “have” the time to learn it step by step. So we created a learning path that doesn’t magically turn you into a guru; likewise, it won’t make you able to fork the Android OS or create drivers for it. However, if all you need is an app that does most of things that 80% of the apps out there do (things like data binding, remote data download, a bit of UI, preferences, menu, input forms, dialogs, page navigation) then your money (just kidding, it’s FREE) is well spent 🙂 The course includes about 3 hours of content and illustrates examples in the context of IntelliJ IDEA Community Edition–the free IDE that Google’s Android Studio is based on.

Get “Android for the Busy Developer” today!

Mobile workshop at DevConnections 2013

I could be wrong but it really seems that I haven’t been in the US for two years now. First week of October, I’ll be back in Las Vegas, proud speaker at the DevConnections show. I will have quite a busy schedule, with three breakout sessions in two days and, to finish with the flourish, a mobile architecture full-day workshop the Friday, Oct 4. Here’s my schedule:

• Oct2 04:15 – 05:30 PM — Fast Facts of Social Network Programming
• Oct3 09:00 – 10:15 AM — Domain-Driven Design, CQRS, and Event-Sourcing for the Busy Developer
• Oct3 03:15 – 04:30 PM — Do’s and Dont’s of Software Projects
• Oct4 09:00 – 04:00 PM — WORKSHOP: Architecting Device-Driven Mobile Web Solutions

I just want to spend a few extra keystrokes here to call your attention on the workshop. It’s about ASP.NET MVC 4 and Bootstrap; you’ll get a complete solution that works beautifully on smartphones, tablets and PCs and IS NOT primarily based on responsive templates.

What??? Read the abstract:

Usually a solution is sought for a clear and well-defined problem. In mobile, instead, sometimes it seems that we’re looking for solutions without having first clarified what the problem is. “Mobile”, however, is a term that is quickly getting obsolete replaced by the term “device”. Any solution that involves mobile devices should be planned for a multitude of devices. This basic fact changes the approach to the design of the presentation layer (and to a good extent, also the application layer) putting the user experience on top of everything and, at least for new systems, taking precedence over domain and infrastructure. In this demo-laden workshop, we’ll first focus on multi-view client-side aspects such as Responsive Web Design and related frameworks such as Bootstrap and AngularJS. Next, we will identify possible pitfalls of Responsive Web Design and ways to work around them. In doing so, we’ll introduce server-side feature detection and device capabilities.

Key passages in the text:

• We’re looking for solutions without having first clarified what the problem is
• Changes the approach to the design of the presentation layer (and to a good extent, also the application layer

Being responsive is obvious and foregone. There will be no point in being responsive in a few months. You must be responsive.

I’d say you must work to provide a responsive experience much more than a responsive design. This is a sort of Copernican revolution in software architecture. And event-sourcing (no matter how implemented, DDD/CQRS/Transaction Script) is another REAL revolution–this one truly the biggest thing after object-orientation.

I suggest you also attend Stephen Bohlen sessions as well if this topic is catching you.