Unperspective: In Your Face
September 16, 2019 Trevor Perry
A few years ago, I was asked to present a keynote session for a conference and the request was something along these lines: “I would like to learn how to change the other programmers in my shop – they won’t evolve with the times.” What a great challenge! I was ready to find the answer.
I spent some time researching this topic, and my initial thoughts were confirmed. Humans, generally, are afraid of change. As we age, our comfort zone becomes smaller – and more comfortable. We know we are good at what we have been doing for years, and we feel that we are successful at it. We stick to it, unaware that the world is passing us in every sense.
In our community, we have a larger population of older programmers who are skilled at development tools from decades prior and can whip up a 20-year-old program in a short time. For us who are in their vicinity, these are the people who need to change. They seem to be holding everyone back, and we would like them to change. Now!
When I presented the keynote session, it was titled “Change Me.” For humans unwilling to, or afraid of, change, there is little to indicate their status quo will be disrupted. My conclusion was that our best path is to change ourselves. We should stop trying to change everyone else, adopt an attitude of openness and acceptance (ok, that’s a little woo woo), and step up to what should be done in our environment. This behavior assures we become champions for our team and our company. We become leaders and examples of best practices. In order to effect change, in order to show the possibility of change, we must change.
I have presented this session several times to various events and conferences around the world. The majority of attendees are planning to learn something at the conference. While there is some trepidation about learning something new and taking you out of your comfort zone, if you are at a conference, you have signaled that you are willing to learn. These are the people who are willing to change. And I expect, that you – the reader – belong to the same group. You are open to learning, open to new technology, tools, techniques, and methodologies. Welcome.
In this column, you will find a unique perspective that is not so common in our community, let alone our world. I am on a personal journey of growth, and for anyone reading my words from 10 years ago and comparing them to my recent utterings, you may have noticed a difference. To learn, I need to always be asking more questions. To learn, I need to be open to challenging my own beliefs. To grow, I need to be willing to step outside of my comfort zone.
As I transition to becoming a full-time speaker, I am focusing on two areas. The first is keynote motivational speaking, for which I have branded myself as Storyteller | Instigator | Agitator. The second is professional development sessions, providing practical commonsense methods to learn topics that are for your personal and professional growth. These sessions will offer a new perspective on what have become tired old topics, with a unique, unexpected, and unconventional approach to your growth.
I will bring those professional and personal development topics to this forum. If you have any topics or questions, please comment or reach out to me. I am open to any requests related to these topics – I have other forums for my take on the world of IBM i and its future!
Today, I will start with User Experience.
In 2000, while I was a Practice Leader at a consulting company in Irving, Texas, I was wearing a ponytail. It was not part of my job, rather it was a style that was accepted in the Renaissance Festival circuit where I was working on weekends in a performance company playing a character and entertaining crowds with street theater improvised inside a character I had developed.
As the web became part of every business, I was approached by management (of the consulting company) to take on an additional Practice Leader role. This group would be the “User Experience” practice. Since I was the “creative guy” (it was the ponytail, I swear), I would run this practice.
My first order of business was to learn and understand User Experience. It was quite simple at the overview level. From the top down, skills were needed to design an application or site that provided an optimal experience for the user. If you consider that you have been to a website where you hated it and would never go back – that’s a bad user experience. If you have been to a website you loved and returned often – that’s a good user experience. From the bottom up, analytics needed to be collected to understand how the application or site was being used. The User Experience practice would engage in both the top down and bottom up tasks.
Obviously, User Experience (UX) is much more detailed than that overview. However, in the midrange world of building applications delivered in a green screen environment, this was a new concept. UX is key to building modern applications, from desktop to mobile, from native to web, from local to remote. Companies must include UX as part of their application development team, whether it is.
Historically, building green screens was intended to collect as much from the user before the (very, very slow) CPU was asked to process that collected data. This led to the more-on principle, where the approach was always “there’s room on the screen, stick more on.” Years of lack of design contributed to suites of applications that simply did not consider the user in any way. As we moved to the Web, programmers continued in that screen “design” role, ignoring all the new and amazing functionality of a graphical or web user interface.
Teaching UX skills to programmers is not always well received. I have fallen prey to the ego boost when one of my applications is installed. Applications are written for the user, not the programmer. Certainly, code is written for the next programmer who will maintain the program, but as engineers, we do love to feel pride in what we have built.
In all the sessions I have presented on UX, only one person has ever been able to prove their formal qualifications in both graphic design and programming. The adage is that one should never let a programmer design a user interface, but that falls short when the green screen “design” expert has not grown beyond that limited interface and their limited skills. It is far too common to continue to show ignorance about UX and deliver applications that fall far short in the usability stakes.
Here are the steps to take to begin the journey to become familiar with UX:
- Get your ego out of the way.
I once offered advice on a poorly designed user interface and the developer took it personally. So personally, that they went scouring on the internet and around their friends to find dirty gossip about me. All that shows is that you are insecure about your “design” or your ownership of the application is far beyond reason. Own up to your failures or missteps or poor design. You’ll only get better if you are willing to grow.
- Study User Experience
You do not have to be an expert in UX. You have to be able to know enough to engage in a conversation with a graphic designer or the UX expert. This level of knowledge will help you become a better developer and in the longer term, your applications will require less design changes as you learn the “rules” and the standards.
- Your favorite color does not work
One of the basics of graphical design and UX is to provide an application that is usable by the entire audience. First, any choice of color or design elements must be undertaken by a qualified expert. You are not. Second, if you choose “blue” and you do not choose the design specification blue color, your page will not be consistent with the rest of the application. Third, if you do not have the right contrast of color, there will be many people who will be unable to read the content.
That’s where you should start. Unless you plan to study a UX curriculum, you will never be a UX expert. I have studied UX for many years, and while I am better at it than most of my peer developers, I am by no means an expert. I can, however, hold my own in a design conversation. I understand usability, design, and represent the users well.
We live in a different world than the green screen haven of our glorious past. We must adapt to the times. We must admit our own shortcomings and be open to understanding how we can change. These lessons apply in our job, in our life, and in our relationships.
We grow, or we get lost in place.
Grow.
Trevor Perry is a storyteller in all facets of his job. He is an IBM Champion, award winning speaker, and author of Never Iron When You Are Naked, the best book you can read one page at a time. If you’d like to suggest topics for this column or have something else to say, connect with Trevor at trevor@urxo.biz.
I agree with most your article but maybe I was “before my time” – I started developing on a System 38 green screen back in 1975 and I have never taken the approach of the “more-on principle” you described. I have always designed my screens to deliver an aesthetically pleasing view of the required data.
Another principle that I follow and that I feel most GUI designers fail on, is to only provide the information that the user needs and give them easy options to select more data if required. I may be considered old fashioned but I do not like the web sites which take ages to load a lot of information that I don’t need, and this could includes pictures. I would just like to get on and do what I need to do and get on with the rest of my life. Don’t get me wrong, there are many instances where a picture can help deliver the required information or collect input; booking seats at a theatre or on a plane for instance but there are many instances where a picture is not required.