Danny Brian
Research Director
1 year at Gartner
19 years IT industry
Danny Brian is a research director in the Application Platform Strategies (APS) team with Technical Professionals Research. His research covers user experience design (e.g., usability, human-computer interaction and information architecture), presentation technologies (e.g., HTMLx, JavaScript, Flash and Silverlight), and requirements management ...Read Full Bio
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.
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:
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:
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.
Category: Application Development Uncategorized Tags:
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.
Category: Agile Application Development Tags:
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:
