Danny Brian

A member of the Gartner Blog Network

Danny Brian
Research Director
3 years at Gartner
19 years IT industry

Danny Brian covers presentation layer technologies, tools and techniques - the stuff people interact with on endpoint devices, and the ways to make it great. Read Full Bio.

Keep Calm and Transclude (Some Thoughts on Angular 2.0)

by Danny Brian  |  December 19, 2014  |  Submit a Comment

I don’t mean to sound unsympathetic. But since the JavaScript blogosphere erupted over AngularJS 2.0 design previews, I’ve been flooded with questions over the “meaning” of the Angular … fallout. This anti-hype is not deserved, in my opinion.

1. It’s a design preview. Angular 2.0 won’t be available for use for at least a year, and I’d bet longer. This means that Angular 1.3 will be actively supported for a likely 3 years from now, and that’s just officially. If some pundits are to be taken at their word, their forks will continue on for much longer. If you just love 1.3, I don’t think you’re gonna find yourself up a creek (without a paddle) anytime soon. Oh, and 1.4 is on the way, too.

2. It’s a major release increment. Some of the criticism seems to be about the design of 2.0, but just as much is aimed at the breaking changes and current lack of a migration path. This is kinda silly; major releases are expected to implement breaking changes. And frankly Angular’s design needs improvement — ask any developer in day 4 of the Angular learning curve. If the dev team weren’t proposing breaking changes, they’d be stagnate and irrelevant within several years. And I’m pretty sure that there will be some upgrade guides out there, whether official or not. Also, see #1.

3. It’s a JavaScript framework. If you spend your days just coding with Angular, I can understand your frustration about some of the proposed design decisions. But this is the Web, and it moves quickly. We should be building lighter front ends. We should be prepared to reevaluate frameworks and libraries on a regular basis. Pace layering is not just a good idea, it’s the law. (Okay, that’s debatable. But it should be the law.) You need to continually evolve the front end — I would argue that your front-end is the “stuff” in Stewart Brand’s shearing layers of change. Backend developers should be so lucky.

4. The change won’t stop here. And it shouldn’t. For those of building rich Web applications, we don’t want to go back to 2005. Honest. And in 2020 we won’t want to return to 2015, I guarantee it. Hopefully you’re paying attention to what’s going on with Web Components and frameworks like Polymer. If some of us get our way, Custom Elements, HTML Imports, and Shadow DOM will become full standards and have native browser implementations within several years. If so, these will change how we build Web applications. Many of the frameworks out there today will be obsolete — we won’t need them anymore. The Angular team needs to stay ahead of this curve, and they’re in a pretty good position to do so. Angular directives give teams a head start the philosophy behind Web Components, as does transclusion and other Angular concepts. Oh, and the Polymer team also lives at Google, which is, you know, convenient. They talk to each other and stuff. Other frameworks including Ember.js and Knockout have also tackled their own enhancements in this vein. ES6 continues to progress (72% support in the IE tech preview, wha?!).

5. Be glad you’re on the open platform. Every day I talk to teams with bigger problems. How to migrate off Flash or Flex or Silverlight? What frameworks to use to target both native iOS and Android platforms? How to get out from under IE8 ActiveX controls? What to do with those mainframe green screen applications? Your Angular 1.3 applications are lucky. They could be around for a very long time, whether or not you decide to upgrade to 2.0 (or 1.4) or not. And equally important, Angular skills will translate well to the next generation, whether it’s 2.0 or Web Components or both or something completely different. (Cuz be honest, that wasn’t easy to learn, was it?)

There’s no reason to flee from Angular at the moment, and there are many reasons to join the party if you’re building rich HTML5 apps. I’m glad the development team is pushing the envelope, rather than resting on their laurels. I believe they will carefully consider the feedback they’re getting from their users — that’s part of the reason for presenting design previews. 2.0 might be great, or it might not be great. I’ll be excited to get my hands on it to find out.

Refer also to #1.

Submit a Comment »

Category: Application Development Uncategorized User Experience     Tags:

Show Me the Requirements, I Will Show You the Solution

by Danny Brian  |  October 13, 2014  |  4 Comments

At Gartner Symposium in Orlando last week, I had just gotten off stage from my presentation “Rekindle the Fire in IT”, rushing to my next meeting. En route, I overheard the following bit of conversation: “So I said to her, look, you show me the requirements, and I show you the solution. End of story.” Here is juxtaposition — I’d just finished an impassioned plea to IT leaders and practitioners to raise the bar on their own profession, and this is the next thing I hear.

A guy walks in to a bar. “Hi Jerry! Something classic and strong, please.” Jerry turns, red-faced. “What do I look like, a magician? Get out of my bar! Come back when you know exactly what you want, and don’t waste any more of my time!”

A girl walks in to a restaurant and orders the special of the day. “Umm, the what?” replies the impatient waiter. “Look, I need a list of your desired ingredients, saltiness, sweetness, savoriness, and textures. I need to know how much you want to spend, how soon you hope to eat, and the quality of food you expect. Come back once you have this information. Oh, and don’t you dare ask for a “pairing”, we don’t do that. In fact, we prefer you bring your own damn drink.”

A woman approaches the cosmetics counter. “Hi, I have a big date tonight and want to look my best.” The beauty consultant laughs. “Sorry. Go to beauty school if you want to learn the tricks of the trade. That’s what I had to do. Besides, I’d need days to fix … well, THAT.”

To the anonymous person whose conversation I overheard. I don’t know your role; your may be an architect, a manager, or even a CIO. You probably work in a siloed IT organization with distrust between business units. But may I suggest that the sponsor who came to you with a poorly defined question gave you a compliment (undeserved, at that) by treating you as a consultant who could guide them through a confusing maze of solutions, rather than just “the guy who plugs it in.” You passed up an opportunity to steer a project down the right path — not just from a purchasing or product perspective, but from the get-go of user needs, of technology direction, reuse, and good architecture. Once that requirements doc lands on your desk, it will be too late to influence for fundamental business value.

The next time you hear someone say, “show me the requirements and I will show you the solution”, I say you fire that person. Hire an expert. An expert who understands that the business doesn’t always know what it needs. That its real needs can rarely be easily captured as requirements. And that it’s the job of IT to point the way.

4 Comments »

Category: Agile Application Development Mobile Applications User Experience     Tags:

Testing Multichannel Web Apps

by Danny Brian  |  June 17, 2013  |  Comments Off

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.

Comments Off

Category: Application Development Mobile Applications User Experience     Tags:

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.

1 Comment »

Category: Application Development     Tags: , ,

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.

 

1 Comment »

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:

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.

2 Comments »

Category: Uncategorized     Tags: