What Car Engineering Teaches Software Engineers about Accessible Control

Car engineers design and develop cars that do not require their users to acquire car-engineering skills to operate. Otherwise, there would be no car for general public. Car engineers provide accessible controls (such as wheels, ignition device etc.) by abstracting away the technological complexities of car engineering in order to provide car controls that are approachable to drivers of the general population.

Does Software Engineering Provide Accessible Controls For Users Today?

Yes and No.

YES because In today’s software engineering paradigm, software engineers use software development platform and tool to design, develop, build and deploy Apps for their users. Hyperlinks, widgets and forms are accessible controls software engineers make available for their users in the Apps they program.

NO because In the current software engineering mindset, software development is to produce apps. User-controls are pre-determined by software engineers, leaving users no room to maneuver for themselves over choices of resources or control over interaction sequence and steps. While today’s Apps are cool and great, they are also very rigid from users’ perspective. Apps do not always perform tasks exactly the way individual users would have done it, had they been given the control. In addition, the exponential growth in number of Apps has becoming unmanageable for end users. We just cannot envision to have one or multiple similar Apps for each and every purpose for every single thing.

For the purpose of illustration, let’s consider the following scenario. No online retailer today is able to unleash their shoppers to shop on shoppers’ personalized conditions and context. What do I mean by that? Suppose shopper Joe wants to buy a smart watch that he has selected for himself from an online retailer as a reward when he reaches his weight-loss goal of losing twenty pounds, as monitored by his Fitbit. He wants to auto buy if the price is less than $400 when his Fitbit tells him his goal is achieved. He also wants to  tweet about it and post it on Facebook when that victorious day arrives.

What Apps today can do that for Joe? Or for another shopper who shops with his or her own personalized conditions and context that are different from Joe? There are countless scenarios from other industry-domains, like healthcare, banking that validate the mounting demand of personalized and situational conditions, context and actions for software users. The extent of agility and flexibility required in software to support it yield infinite permutations of combinations in the usage of resources and interaction flow that today’s software engineering paradigm of “Apps” is not designed for and cannot handle.

Until users are unleashed to freely task,

there is no Accessible Control for Software Users in Software Engineering

Is “Accessible Programming” for End Users an Impractical Oxymoron?

To address the requirement of giving greater control over to software users, much work has been done in the area of “End-User Software Engineering” (EUSE). The premise of EUSE is that if we can find ways to simplify software engineering and programming to a form that even non-professional programmers can learn and master, then end-users have a much wider spectrum of control over the software they use. If still not what users want, at least they are enabled to develop their own. On this premise, non-professional programmers such as business users are provided with easier to use, user-friendlier software development platforms and tools with much improved builtin assistance. Program by example, Scratch from MIT, various mash-up platforms, various visual programming platforms are typical examples of EUSE. Other branch of EUSE as in “What You See is What You Get” (WYSIWYG) requires users to acquire skills in languages in users space, such as scripting languages or domain-specific scripting languages as in Chickenfoot or Grease Monkey.

Harvesting the wisdom of accessible controls observed in car engineering:

The underlying engineering cannot be the starting point of accessible-control design. The starting point of accessible-control design must start by stepping into the shoes of users, whose primary concern is their tasks at hand.  

Can EUSE be ever simplified enough to be considered as “accessible controls” by software users of various industry domains and general public? Is “accessible programming” in fact an oxymoron, too impractical to be used for software users’ day-to-day tasks?

No matter how simplified, any EUSE related development environment, platform and tooling is still engineering and programming done by end users whose primary concern is not programming but their tasks. Nevertheless, they are given an integrated development environment (IDE) of some sort, being put in the programmers’ seat, asked to design, develop, build and deploy Apps.

“Programming Proficiency” is not as related to Accessibility as “Complexity Appropriateness” in light of users’ task at hand.

EUSE runs on the underlying assumption that to lower the barrier of user control, simplifying programming is the way to go. However, such pre-assumption completely misses the point that many times, programming is a complete mis-fit to the users’ task at hand, regardless of the users programming proficiency. This has been validated in healthcare [1] and other industry domains. Can you envision how our shopper Joe from the scenario mentioned above would apply EUSE to meet his own personalized online shopping requirements, whether Joe is a proficient software engineer or not?

Rethink Software Engineering for Accessible Control as Parts Beyond Apps as Whole

It is time to rethink the current paradigm of software engineering of Apps programming, motivated by finding answers to the following question:

How software engineering can provide units of accessible controls to be put in the hands of end users, such that they can agilely put together tasks for themselves without the need to acquire programming skills or knowledge in technologies, and without depending on IT.

End-user programming (or EUSE) is to put end users in the shoes of software engineers. This will never get to the level of accessibility that users required for their everyday need.

The starting point of rethinking software engineering is to reverse this mindset, starting by putting software engineers in the shoes of end users, with the engineering goal of providing end-user controls that are accessible.

With software transformation driven by cloud and Internet of Things (IoT), this software engineering rethinking of providing units of accessible controls to unleash end users will have profound implications and pervasive impact across the board, as we are more and more awakening to the rigidity and inflexibility of today’s Apps, to the point that drives us to engineer for better alternatives.

Introduce “TASKING” as a New Software Engineering Paradigm

I define Tasking as a new software engineering paradigm upon which software engineers and programmers produce units of accessible controls for end users to consume. End users, on the other hand, use these units of accessible controls to put together tasks for themselves to handle their own personalized and situational needs, completely unassisted and independent from IT.

Units of Accessible controls for tasking that are natural for users may include the following elements:

• Schedule and frequency of the task
• Conditions for the task to be done
• Action or sequence of actions of the task
• People to be notified about the task
• May be others

IFTTT and Zapier demonstrate a portion of this tasking paradigm, enabling end users to autonomously and freely associate their tasking elements, called  triggers” and “actions”, on the IFTTT and Zapier platforms.

Good Software Engineering for units of accessible control for Tasking should demonstrate the following characteristics:

• It is open in architecture: open for IT to contribute, open for users to consume and freely task
• It is interoperable by design
• It provides metaphors, mental models and cognitive representations for users to put tasks together in manner that is natural from users perspective

I will publish more entries on Tasking in the days to come.

I am interested in forming an open community around Tasking as a new Software Engineering Frontier.

If you are interested, please do not hesitate to contact me by email: jwng@ca.ibm.com or follow me on Twitter: @joannawng

Tags:

#webtasking #tasking #REAST

Other Related Articles and Publications:

Wikipedia on “Web Tasking”

Empower Users with Web Tasking

Software Engineering for Tasking: Adapting REST to REAST

Tasking as a Service: IEEE ICWS 2015

References

[1] Yu, E., Kealey, R. Chignell, M., Ng, J., Lo, J. “Smarter Healthcare: an emergency physician view of the problem”. The Smart Internet, 2010 – Springer.

General Disclaimer for All public social media entries that I authored and published: they only represent my independent thinking as a technologist in the industry and may or may not represent IBM’s positions, strategies or opinions.