We’ll be talking a lot about Web technologies and multichannel strategies like responsive design at the upcoming Catalyst conference. Here is a preview of that content.
Category: Application Development Mobile Applications User Experience Tags:
Danny Brian
Research Director
1 year at Gartner
19 years IT industry
Testing Multichannel Web Apps
by Danny Brian | June 17, 2013 | Submit a Comment
The Renaissance Developer (part 1)
by Danny Brian | October 4, 2012 | Comments Off
Nearly every day, I overhear someone remark on how dramatically the world of technology has changed. Mobile. Social. Cloud. Information. If most professionals think their lives have changed as the result of this nexus, just imagine how developers feel! Our world is barely recognizable. Some developers welcome this change, and rise to the challenge. My team calls these folks “renaissance developers”, and we’re not just trying to be clever here. These are folks who thrive on the new. They welcome the revival of interest and passion in great technologies. They know they have a lot to gain by adopting new tools, languages, practices and patterns. And they are some of the most valuable individuals in your organization.
My document “The Renaissance Developer: Skills Guidance for Modern Applications Programmers“ is now available to Gartner for Technical Professionals subscribers, and helps developers and managers meet these new challenges. How do developer skills need to evolve? For what types of competencies should you be hiring? What practices will encourage this evolution? Deep, very deep.
Over the coming weeks, I’ll be posting a series about this individual — elusive to some, familiar to others — known as the renaissance developer. Some of the content is drawn from one of my presentations by the same name. It features Craig.
As you can see, Craig brings to the job a veritable toolbox of skills. He is the prototypical renaissance developer, and there’s a lot more to him than meets the eye.
More next.
Comments Off
Category: Agile Application Development Tags:
Adobe Edge is Kinda a Big Deal
by Danny Brian | September 27, 2012 | 1 Comment
I spent many years building Flash and Flex applications. A lot of the criticism leveled at the browser plugin had nothing to with the technology, and everything to do with the type of content developers built with it. Sure, plugins did require a bit of bending to users’ mental model, but was that really a bad thing?
Flash gave us the browser we wanted, long before we would actually get it. It formed many of our current ideas of what the modern Web could be. The tools to build content for the Flash runtime were not perfect, in part because they tried to straddle the worlds of creative professionals, coders, and applications developers. But as a platform for development of native and desktop applications, Flash remains an important part of the entertainment software ecosystem, and will remain that in the foreseeable future. If you doubt it, check out this video of the new Farmville 2, built by Zynga for Flash Player 11. Purty.
I moved on from Flash development to pure Web development some time ago. As much as I like the standards-based approach, the dearth of tools to help with Web development has always been notable to me. At this week’s Create The Web conference, Adobe unveiled seven new tools and services focused on Web development. Many of these tools have been open source projects to this point, now available as commercial offerings via the Creative Cloud service. The functionality here is impressive.
- Edge Code, based on the open-source Brackets project, is a code editor for HTML, CSS, and JavaScript. Because it is built on those same technologies, it’s aware of all the relationships between code and files. Put the cursor on a JavaScript function call, and you can open the referenced code inline, regardless of the source file’s location. Need to tweak colors? Use the built-in color picker. Edge Code also lets you open a live preview in Chrome, meaning developers never have to switch to a browser and hit reload in order to see changes.
- Edge Inspect lets you expand these live previews across mobile devices. As you tweak CSS and JavaScript, changes occur in real-time across wirelessly-connected devices.
- Edge Reflow (not yet available) is an authoring tool for responsive design. This gives you visual control over multi-channel Web development, with CSS3 media queries represented as draggable bars. The tool gives you command over how elements get hidden, revealed, scaled, or otherwise manipulated on devices of different sizes and form factors. The time this will save me…
- PhoneGap is a great tool to bring Web technologies to the app store, but maintaining local SDKs and building these apps on the desktop has never been particularly easy. PhoneGap Build is a service that packages up mobile Web apps in the cloud. Upload your files, and watch as a native-ready version gets built for all the popular mobile devices. You can then scan a QR code with your phone to automatically load the app onto the device, with a start-to-finish time of minutes.
- Edge Animate is a Flash-like authoring tool for animated content. You get intuitive keyframing and other features familiar to creative professionals, but targeting HTML/CSS/JavaScript.
- Edge Web Fonts gives you a large library of free Web fonts hosted by Typekit.
- Typekit is adding 500+ new Web fonts.
As valuable as these offerings will be to Web developers, equally impressive to me is the overall attitude behind the Edge tools. All of the tools provide easy access to code, rather than attempting to abstract away any elements. The Adobe Edge teams clearly understand the modern Web coder better than many: Web coders want tools that help to solve development challenges, rather than solving them outright (because that has never worked well). These tools do nothing to step on the coder’s toes or limit integration options.
The corollary to this developer friendliness is that the Edge tools are highly agnostic to both server platforms and Web frameworks. You can use them as part of workflows to building applications for Rails, Node, or even Sharepoint. Full-stack integration could be part of Adobe’s applications strategy of the future (as with LiveCycle and Flex), making for a turnkey enterprise offering. But I hope the Web development community receives the Edge tools and their open source projects with sufficient enthusiasm to show Adobe that the task-focused, non-prescriptive approach is the right one. If and how a business model gets built around these (currently free) tools is another conversation. For now, I’m just going to enjoy using them.
Category: Application Development Tags: adobe, css, javascript
Several Thousand Sticky Notes Later
by Danny Brian | May 4, 2012 | 1 Comment
During my career, I’ve helped to spearhead multiple User Experience initiatives. The key to this undertaking is to conduct ongoing user studies as part of development iterations. Where analytics seeks to make sense of quantitative data, user studies seek to answer qualitative questions about users and their use of software. What are users thinking when they land on your Web site? Why are they confused by the names of your labels? What was it that clued them in on the fact that they needed to use the search field to find what they needed? How could they have gotten what they needed more easily? User studies are a form of contextual inquiry (CI) and ethnography, and tend to uncover valuable data points not easily discovered in other ways.
When I joined the Gartner for Technical Professionals group, I knew very little about the internal research workings. When I was introduced to GTP’s contextual research (CR) process, I was thrilled that a similar process was already in place. While it’s true that a constant flow of inquiries and dialogs with customers helps to fuel our research and opinions, contextual research is our opportunity as analysts to “just listen”. This is real, deep inquiry:
- We find willing candidates with real world expertise in a given technology space.
- We isolate these interviews from any consulting. We try to be observers, and let the interviews challenge our preconceptions.
- We isolate interviews from sales activities. Many of the participants in the research interviews are not Gartner customers.
- We visit interviewees in their own work location for several hours.
- We ask open-ended questions about their challenges, experiences, and opinions.
- We gather the findings via multi-hour interpretation sessions, involving the CR team.
- We distill findings with a massive consolidation session. Attached is a photo of one corner of our consolidation room.
- We create new documents for our customers to offer insight in to industry evolution and trends.
Elden Nelson, a.k.a. the Fat Cyclist, has written an excellent primer on our contextual research practices, available to subscribers of Gartner for Technical Professionals content.
Right now, I am participating in such a CR project, this one aimed at mobile application development. The interviewees have included publishers of a #1 app in the Apple app store, large services organizations, small startups, major software developers, manufacturing companies, financial services, and everybody in between. We wrapped up this morning after an entire week in a Gartner conference room. 1,300 data points were tagged, grouped, debated, distilled, debated, annotated, debated, and summarized. And can I say, we emerged with some very insightful (and surprising) conclusions. From this project, multiple field study and other documents will provide recommendations to organizations developing mobile applications.
It’s hard to quantify the value of such insight gathered across verticals, a broad spectrum of technologies, and a myriad of development practices. When you read our research or speak with analysts, you’re not just getting an opinion. You’re getting knowledge that has been refined by a lot of behind-the-scenes inquiry and disciplined (and difficult) interpretation. Pure research is one of the best parts of my job, and doesn’t get enough coverage for our organization.
Category: Agile Application Development Mobile Applications Tags:
Server-side Template Engines Aren’t Going Away … Yet
by Danny Brian | April 19, 2012 | Comments Off
My document “Application Frameworks for the New Web” is now available to subscribers of the Gartner for Technical Professionals content. The analysis defines four very broad categories of Web application frameworks:
- Portals and Content Management Systems (such as SharePoint, Drupal, DotNetNuke)
- Traditional MVC frameworks (such as Struts, JSF)
- Convention over Configuration frameworks (such as Ruby on Rails, Grails, Spring Roo)
- Event-driven frameworks: (such as Node.js, netty, Meteor)
The event-driven framework is the newest breed, and Node.js is the most popular in this category. You can use these frameworks to build traditional style Web applications, but the frameworks really excel with the single-page genre of Web applications. That is, Web applications which load a complete Web page once, and thereafter load data dynamically and manipulate the loaded page in memory, rather than making full-page round trips to the server for new pages. There are many well-known examples of this style, but Facebook is the most popular. The genre is fueled by an increase in Web browser capabilities, a more advanced JavaScript frameworks, and evolving user expectations. And by the way, it was and still is entirely possible to build such single-page apps without any HTML5 features, but people increasingly refer to this style of application as “HTML5″. Go figure.
Event-driven frameworks are quickly gaining popularity, especially for development cases that require constant streaming of many small pieces of data. In such cases, no server-side template engine is necessary, with all rendering being left to the browser via JavaScript DOM manipulation. In this model, it is still possible to build traditional round-trip Web applications; generating the HTML can be deferred until a browser has loaded all JavaScript and data, with each click of a link repeating the full page request. But that begs other questions, namely, why not load only the bits of data necessary, and save the network overhead?
The event-driven framework has been repeatedly heralded as the death of server-side template engines, but this is premature. (Remember client-side XSLT? Anybody?) As far as browser JavaScript has come, we still lack a solid understanding of best practices for it being used as a full-blown application framework. And no, for all its awesomeness, jQuery has not given us such a framework. That’s not to say we don’t have a good idea of where the platform is going. Companies like Sencha are starting to fill many of the gaps that have, until now, prevented the enterprise from going full bore with single-page Web applications: IDE integration, deployment practices, WYSIWYG tools, clean object orientation, strong data typing, data binding, and so on. But today, the most popular single-page apps are still getting developed with a large and costly combination of multiple frameworks that include some from all categories. Even where older browsers do not need to be supported, many challenges still exist to building high-quality, “thick client” Web apps. In other words, we’re a long ways from the enterprise being able to easily roll their own custom-designed, fully featured, single-page Web applications.
Is the popularity of single-page applications a positive development? That is still open for debate. Pushing processing client-side helps with scalability and makes apps easier to build and maintain on the server/cloud, but the tools and clear practices for browser-heavy JavaScript development are still in their infancy. Meanwhile, concerns surface about consistently well-designed (and accessible) URLs, preservation of the Back and Reload button behaviors, and RESTful principles being applied properly to Ajax interactions. The more important question is whether users’ mental models of usability will increasingly expect the rich interactions. For many users, the difference between single-page Web apps and traditional Web apps could be as simple as whether a “please wait” spinner exists inline to the Web app, or at the top of the browser UI itself. Several of my recent research engagements suggest that users look for the inline spinner and, not finding it, often think something has gone wrong. The trend towards these rich, responsive interactions seems clear, and the logical conclusion of the trend is the single-page app.
I’ll be hosting an analyst user roundtable at this year’s Catalyst Conference to discuss the merits and drawbacks of the single-page web application paradigm, and will be curious to hear the opinions of conference attendees.
Comments Off
Category: Application Development Uncategorized Tags:
Under Commit, Over Deliver?
by Danny Brian | April 12, 2012 | Comments Off
Most of us want to do “good work.” In the world of software development, that means delivering results that meet the expectations of project sponsors. Those expectations can apply to timelines, quality, and features. When results do not match expectations, the relationship deteriorates between sponsors and delivery teams. We’re all familiar with the ways the problem gets mitigated: Sponsors overload requirements, asking for more than they expect, and development teams buffer estimates.
I’m as guilty of this mentality as anybody. “Under commit and over deliver” has been one of my mantras in directing multiple development teams. Whether or not the concept has a place in modern development, it is symptomatic of underlying organizational problems. When stakeholders and sponsors are involved in proper Agile planning — participating in backlog creation, attending iteration reviews, and engaging product owners on priority discussions — sufficient transparency can exist that sponsors know where things stand, and developers know what sponsors expect.
However, when systems such as Agile are practiced only within development teams with the higher-ups sticking to Waterfall expectations, those broader benefits of Agile get lost. This can end up working, but only with exceptionally talented product owners capable of translating between the two worlds. And in such a case, expectations still get managed via under commitment and over delivery. And really, when was the last time that any siloed project surprised the sponsors with its great quality, design, and feature set? If it did, I’d bet expectations were particularly low. As in, that-team-has-zero-credibility-and-we-don’t-have-any-idea-what-they-are-doing low.
Modern development methodologies need to do better. We’re seeing the increasing overlap of technical and leadership roles within organizations, and this is positive development. IT leaders are more involved in the technical details, and IT professionals care more about the underlying business value of their day-to-day work. (More on this in upcoming research.) This convergence is a lot of what makes Agile development possible, and has given us the opportunity to care more about the soft elements of the user experience and solicit innovation from all levels of the organization. By involving all stakeholders in project iterations, sponsors have no excuse for not being aware of project status and direction, and contributors can have confidence that their work aligns with business priorities. The involvement of all stakeholders in the process is a critical but often overlooked aspect of iterative development.
Great applications with great user experiences come from organizations that are fully engaging the iterative paradigm. In a world where the user experience defines a company’s brand, all sponsors should be committed to this development model. The next time you hear someone talk of under commiting and over delivering, point out that it shows a disconnect between sponsors and delivery teams. As far as it is within their power to change, they should seek to narrow the gap. Where sponsors desire no real involvement in the process, we will continue to pad estimates and misrepresent status. It’ll work on some level, sure, but it will also perpetuate the division between IT and the rest of an organization. And both have too much to offer the other to continue that way.
Comments Off
Category: Agile Application Development Tags:
Thoughts on “Mobile First”
by Danny Brian | February 8, 2012 | 2 Comments
Did you hear? More smartphones than PCs were sold in 2011. To add insult to injury, PCs as counted here includes tablets, which now make up 15% of PC sales.
Among the analysts covering application development, we’ve have had a lot of discussion lately on the development practice known as “Mobile First”. The recent conversations centered largely around this article on Forbes concerning the development of ESPN’s video applications, and their own use of the Mobile First concept. Opinions among the analysts vary on the subject. Any practice with “first” in its title is rightfully suspect, because on the surface, it implies a universal best practice or silver bullet with no context on what is actually occurring inside an organization. But on a closer look, this is a pretty common-sense approach to designing web applications.
Luke Wroblewski coined the term in this post, and has now written a book by the same name, which I finished a few days ago. Some takeaways:
- The mobile explosion is in the books. It’s likely that in the near future, you’ll have more potential mobile users than desktop users. Why would you want to alienate them?
- Designing for mobile imposes constraints. Constraint is a good thing for the user experience, because it forces you to evaluate the value and priority of your use cases.
- The new capabilities for mobile (geolocation, touch, phone integration, cameras, accelerometers) can support new and innovative use cases. You can’t take advantage of them if you start with desktop use cases. (Of course, you can’t easily adapt the resulting application for the desktop, either.)
- Content is more important than navigation on mobile. It needs to feature even more prominently. Navigation has to be streamlined, expected UI behaviors need to be obvious, and actions should be highly contextual.
- Progressive enhancement — scaling a web app’s layout and features to suit the accessing device — can be an effective way to adapt an application to multiple platforms.
When a team sets out to build the client side of a web application, they have to start somewhere. Historically, that meant building for the desktop, and later adapting the application with new templates to server a mobile-friendly interface. This approach rarely delivered positive results, in part because the use cases for the application were created for the desktop. You’ve seen these in the wild when you land on a web site with a mobile phone: They’re easier to read and use, but don’t offer much by way of value or even enable the features you want to access. Great mobile web applications are designed specifically for mobile. How well those results can be adapted for non-mobile devices is debatable, and depends largely on the type of application and mobile features that were used.
It’s worth noting that the concept is finding its way into specific implementations for application development frameworks. Some are using the jQuery mobile libraries to enable easier progressive enhancement. More on that another time.
To be clear, we’re talking about web applications here. You might think, “well we’re doing native app development, so this doesn’t apply.” However, if you have a web site (and you probably do — check on it, at least), you have a web application. If you have a URL that can be accessed from a mobile web browser, then that URL is getting shared via emails, IMs, tweets, and other sites. Are mobile users who follow that URL getting a positive impression of your brand? Your chances at “yes” are far better if you designed the app specifically for mobile, whether you tackle it first or not.
Category: Uncategorized Tags:
