Why Development Frameworks are the Devil

From the perspective of a User Experience professional, the use of development frameworks has to be one of the most significant limiting choices an organization makes when deciding to build software User Interfaces.  Before we get too far along, I want to be clear on what I mean in regards to what a “Framework” is in the context of this conversation.  I’m talking about the set of tools/products and libraries teams use to develop and test Web applications.

Don’t get me wrong, I get it…the appeal, a company’s desire to have a standard set of components, expedite and simplify development/test, and a horde of other false promises the tasty Framework of the week offers.  I am in no way saying UI development frameworks can’t be successful, there are many examples out there for great applications being built using frameworks.  However, I have yet to experience an organization’s ability to take a collection of complex products and rely on one single framework strategy to solve complex sets of functions that span those products.  If your organization has a limited product catalog or a few simple products that can adapted quickly…a framework is probably a good choice.  If you don’t have the expertise in house to develop a set of standard components and UI guidelines that will evolve with the company’s strategic direction; it makes sense to rely on a framework, rely on those who have supposedly invested time to provide usable constraints in which to deliver functionality.  But prepare to deal with their way of delivering; there may be little room to adapt UI interactions to meet end-user’s needs and thus a limited or unusable experience for your use cases.

I firmly believe that if you have experienced (aka expensive, but awesome at their job) people developing your User Interfaces, the need for the heavy and unforgiving frameworks all but disappears.  Some frameworks are more forgiving or flexible, while others provide a strict model by which deviation quickly extinguishes any hope for development savings.  So, why are Development Frameworks the devil?

They don’t typically enable enterprises to make design and interaction choices that benefit end users for relevant use cases.

Here may be some practical points to consider:

Time to market, ramp up of design, development and test skillsets

We’ll leave the research phase out of the discussion, once an organization chooses a framework and the relevant technology stack needed to support it, personnel will need to get trained appropriately.  Outside help is another option, assuming it can be found in the timeline constraints for the project(s).  With the increasing pace of these frameworks, by the time the teams are proficient enough to be successful, it’s almost always the time to move on to the next best choice…the cycle continues.

Expertise hard to find

Cutting edge means the internal talent pool likely isn’t up to speed on the latest trends, outside help will be expensive and hard to find.

This is inherently risky for increased time to market; as people learn as they go, the lessons learned won’t apply to the next iteration…which can be too late.

Unattractive (non-sexy) framework choices are less desirable to developers, despite potential usability benefits (again, users not at front), people want to build the skills around what is marketable and what is enjoyable.

Competing frameworks may negatively impact usability

Within an organization, if you have various frameworks in play for UI development, this may not be an issue.  It does become an issue when products and/or functionality is integrated.  Frameworks have their own ways of enabling users to complete tasks, users can very easily pick up on variations (not always a bad aspect of usability), this can lead to conflicting interactions that may lead to usability issues.

Legacy application incompatibility – look, feel, interaction…all different

If you have existing applications, it is likely that your viable legacy UIs will have to be rewritten in parallel with your new applications being developed, if you’re looking for a consistent experience across your products.  If you are brand new or only have 1 or 2 small products, a framework may help compliment your strategy.  However, it may be helpful to choose one that has common design standards but also manages change well…especially if your organization is concerned with aesthetic vogue.  Otherwise, you may find yourself adopting new frameworks every few years, forcing an eternally inconsistent user experience and an even more challenging internal development environment.

Cross browser compatibility

Do you care about cross-browser compatibility?  If your organization is pushing for modern modern modern, ensure this dovetails with any existing legacy applications you may have to support.  Is there funding to update the UI layer of those legacy applications?  If not, going modern and pushing your users to adopt modern browsers may cause a very serious problem.  OR the other problem, not realizing your users don’t have the ability to upgrade to a modern browser may leave them unable to use your modern application UIs.  For example, have you tried to use Angular/Bootstrap in IE 8?  Have you tested your applications in IE11, chrome, safari, FF?  The devil is definitely in the details when it comes to the ability for users to even access content across browsers.  It’s absolutely fundamental to know what you NEED to support and what you want to support long term.  So, does your framework choice enable or hinder cross browser compliance?

In Closing

These days, I’d much rather work with a team of people who are skilled in HTML5/CSS3, Jquery, JS, etc. than those who know x,y,or z framework.  I firmly believe that a solid team who know the fundamentals of web application design will vastly outperform and create a more attractive, usable product than a much larger team of less-skilled individuals utilizing a rigid framework!  I believe it’s primarily the short-sighted financial decisions that lead to the adopting of frameworks in general, organizations don’t want to pay skilled labor wages.  They think they can short cut the process by buying a framework (or going open source) and paying less skilled people to drive as the framework allows.  If your organization is following user-centered design, you’ll more than likely find that what users want, how they need to interact with your application in order to be most successful will NOT be in alignment with what the framework will allow!  And that, my friends, is why frameworks are the devil!

Modern Browser Compatibility and UX

We are in the midst of a quagmire, and not the giggidy giggidy alright kind…I’ve recently been tossed into the fray of deciding how best to determine a browser strategy that will meet both the needs of existing customers as well as not prevent our organization from adopting modern Web technologies that don’t necessarily yield the best results in legacy browsers.  For example, if you’re writing Angular applications, I am hopeful none of your users are on IE 9 or less – yes, some people are still using OLD IE browsers!  What does UX have to do with a company’s browser compatibility strategy?  After all, this is a technology decision right?  In my opinion, we should definitely be a strong voice in the decision, but shouldn’t own it.  Ensure your stakeholders understand the impacts of the decisions being made so that any browser compatibility initiatives are aligned both with end-user needs and business expectations.

A few quick takeaways for those who are into the brevity thing:

1) Know your users as well as where you want/need to be now and a few years from now – don’t get too bogged down into the details of the analysis, the major gotchas will become evident quickly (basically, you don’t need to know the entire picture before taking action).  The needs of an E-commerce site could be very different from an Enterprise site or Business-to-Business Web application.

2) There isn’t a single, one-size fits all solution (as always) – a prescriptive approach is necessary but must be precise and will be determined be each organization’s situation.

3) Pick an approach that is doable in your environment (current product road-map allows for work required to implement change, funds are available and management is behind funding these changes, expertise is available for the desired technologies, and the organization is ready and willing for change!)

The details…

Take the time to understand your users and what is driving their current usage patterns.  The more empirical usage data the better you’ll be able to focus on which facts require in-depth research! However, the usage data cannot stand on its own, it is imperative to know the “why” behind the “what”.  Do you have tech-forward adoption with new technologies or are your users stuck on legacy operating systems with legacy browsers?  Are your users in the process to upgrading and you don’t know?  These are just a couple of questions that could impact strategy that wouldn’t be understood from the raw data alone – some legwork and talking to your users is necessary.

What is industry doing?  Quick searches to industry leaders and competitor’s products will yield enlightening and straight-forward directions; some may work for your situation, some could lead to disastrous results.  Either way, it’s a positive step to investigate what other teams are doing to understand a baseline goal of what you should achieve and how to communicate the message appropriately with your users.

Once a basic understanding of how your products are being utilized is complete, it’s a good time to revisit what the organization was hoping to accomplish via potential changes and determine the correct course for action.  With route A, will your organization be maximizing future potential without jeopardizing current relationships?  With route B, will your organization be too focused on current relationships that don’t provide enough revenue and risk profitable, future relationships for the sake of ‘now’?  There are number of variables and we could go on and on, you have to choose what makes sense for your organization’s goals.  I chose to focus on products and customers that provide the most revenue and strategic importance in balance with which products had the highest usage.  For example, you may want to evaluate all the squeaky wheels to see if more resources are being spent to appease them than they are worth…it can be shocking sometimes.  It makes sense to focus on business-driven decisions in conjunction with the usage data to come up with a strategy that is timely and most importantly DOABLE.

It’s ineffective to develop a strategy on which your organization is not prepared to execute!

Testing – The Potential of the Problem

One of the first steps that should be taken is to test your products to ascertain the current level of compatibility across the browsers/versions that will be supported.  This simple exercise can actually be complicated because it will likely require your testing teams to have or emulate multiple browsers and modes.  In traditional IE shops, this will likely mean training and potentially some technology purchases as well.  In addition to the technical/practical changes required to test across browsers, you’re taking the testing teams away from scheduled test schedules…which will have a variety of impacts on established product delivery dates.  It’s essential to note the UI features that are problematic across browsers.  This way, the adoption of those problematic elements in future design/development efforts can be weighed with their necessity, usability, and impact of extra dev/test time required to manage them.  One thing to note is Internet Explorer and the variations of compatibility in native, compatibility and enterprise modes when a user is running IE11.  If you care about supporting legacy applications in modern browsers, evaluating the various mode combinations in IE11 may be a valuable option.  However, you may find that most of the issues are viewing modern applications in legacy browsers, especially any UIs that are laden with JavaScript.

All Aboard

Now is a great time to start getting all the internal stakeholder teams on board with what has been discovered.  The earlier the better.  You don’t want to surprise your product teams with a “hey, we’re now supporting x, y, and z, you better get on the train, it’s left the station” sort of impression.  Top down support is essential.  Influence management is a positive approach.  However, you may not have the time it will take to be effective via influence alone, especially in an organization supporting many sets of products when you’re trying to achieve a single strategy.

One decision to weigh heavily is what an organization will do with legacy application while they are tossing older for emerging technologies.  Is this a UX problem?  Well, it is if you’re dealing with an experience that spans multiple products/pages/applications that utilize different technologies and have different experiences in different browsers.  If your organization is adopting responsive/adaptive UI development techniques you may be able to leverage those practices as another method to address a product set with varying compatibility.  Specifically around users who have older browsers. Supplying different fidelity UX in an adaptive model will provide your users a positive experience. Those with older browsers can get dished content in a less dynamic/flashy UI than those with modern browsers, all the while the business logic remains the same.  But then again, this requires a disciplined development team and an abstracted UI layer…all of which come with a higher price tag to implement.

Does your shop have the expertise to support the development changes that will be coming? Is training feasible, how bout outsourcing?  How does the potential to outsource impact morale?  How will utilizing a set of new tools/practices be received?  All questions to consider!

Unless your organization has unlimited resources, prioritize the changes accordingly.  It’s unrealistic to think you’ll be able to make the changes all at once across all products.  Utilize whichever decision method makes sense for you organization to identify a set of ‘first round’ products to test and schedule development accordingly.  Then follow-up with the lesser priority products until the compliance review and execution is complete.

Where’s the Beef?

Or cheese I guess it should be…Where’s the money?  The plan is on paper, people have bought in…but nothing is going to happen unless dollars are allocated.  Dollars get the training, the outsourced help, the time allocated, etc.  This isn’t last, this is first.  However, having a clear view of where products stand and how big the problem is can paint a picture management can understand and buy into, literally.

One more thing to consider.

The allure of new technologies is going to outpace adoption; it takes too much time to get resources up to speed compared to the rate at which they’re coming on to the scene. This problem is exacerbated the greater an organization’s product set becomes. Industry trends like are competing and these days they are less stable, even the ones that do win out.  Angular is doing well, but Angular 2 is coming, there a dozen others out there doing OK,  Polymer is showing promise, who knows what else in the near future?  Regardless, it isn’t effective to adopt every year, or maybe it is for your organization?  However, more than likely, it makes sense to evaluate annually and plan for the next 2-3 years on as few of technology choices as possible and know the impacts of technology choices on your cross-browser compatibility.

In Closing

Regardless of technology choice, make a plan to support modern Web standards (like HTML5/CSS3) rather than certain browsers – If necessary for your users, ensure you maintain backward compatibility to suit the those needs.  Having an abstracted UI layer will ensure your products can be upgraded as new technology choices are made.

Before starting your browser strategy, these steps may be helpful to keep in mind:

  • Understand your users
  • Test your products across browsers you plan to support, document the current state of compliance and determine problem design elements that should be avoided
  • Determine if your current certification meets your user’s needs, both current and future
  • Develop a prioritized approach that is in alignment with your user’s needs, involve internal stakeholders in the planning to achieve maximum buy-in
  • Ensure the plan is doable within your environment, set your organization up for success
  • Communicate the plan with your customers
  • Rinse and repeat!