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.
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.
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.
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.
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.
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 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 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.
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.
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:
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.
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.
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.
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.