Well, that’s what my friends parents assumed since all I talked about was the music gear I kept buying. I believe their comment to my friend was, “how on earth could he have that kind of money while unloading trucks at Dayton’s!?!”.
Truth is I just never spent a cent on anything else. If I couldn’t play it or drive it, it never really was of interest to me.
I loved buying and talking about gear. “I love my new Oberheim Matrix 6…especially the…”, or, “You’ve GOT to listen to this new patch on my Korg Poly 800″… and on and on. The vibe, sounds, (and smells) of “Knut Koupee”, “Torps” or “The Good Guys” are some of the most fond memories I had growing up.
Over the course of a year, I created a respectable electronic studio where I created some pretty cool sounds and songs
But through all the analog goodness, I discovered one thing that the music instrument industry got right that almost no other consumer industry has yet to achieve:
Interoperability. <yawn>
I know. Boring. But it’s true.
MIDI – Musical Instrument Digital Interface…an inter-company interface that let one electronic instrument (synth, drum machine, sequencer, …) talk to another, regardless of who built it.
For me, a musician, MIDI enabled the ultimate user experience: MIDI lets musician use the tools they want, to create something new and wonderful, without having to adjust their behavior due to greed, or fear, or whatever it is that prevents companies from providing complete interoperability.
Further, the musical instrument industry blossomed! Nobody was trying to “build their ecosystem”, or “Capture the market”, they were driven to create amazing instruments to delight their users … they were trying to outpace their competitors not in proprietary environments, but in awesome sounds…awesome experiences.
Some of my favorite moments is composing a song with the following all working seamlessly together (ready?):
Keyboards (modules):
Yamaha DX7
Oberheim Matrix 6
Korg Poly 800
Roland RD-500 (which could talk to all of them at the same time)
Roland XV5080
Proteus 1
And it was all synched from my click track on my Yamaha MT1X 4-track recorder where my vocals and guitar tracks lived.
Look at all the companies that focused on the user! (I know, you’re about to say, ya, but some of them are not in business…and while true, it was mostly from the analog/digital wars…impressions that analog synths were crap…which we now know they’re awesome…and just another set of tools to help musicians create amazing art)
But there’s hope!
Just yesterday Amazon and Microsoft announced that “Alexa and Cortana have become friends”. If they really are working for full interoperability, I think this could be the beginning of exponential growth in great experiences. The skeptic in me is wary since they’re currently just passing control to each other based on user commands like “Alexa, open Cortana”… which creates ‘modes’, an awful experience.
VIDI
But just imagine…what if there was VIDI: Voice Interoperability Digital Interface; where a user could just speak into the air, and all the variety of voice assistants would chat amongst themselves to see how which one…or which combination of them…could delight the user…
THAT is a future direction that is truly focused on user experience…and one that could see growth in the industry that would dwarf where it is now.
Here’s to the future learning from the past: How a growing industry can achieve UX greatness…delivering outstanding user experiences, interoperability…and here’s to MIDI…the technology EVERYONE should love because it is a shining example of what can happen if we collectively work to delight our users by just making our stuff work together.
To read more about the Alexa and Cortana friendship, start here:
One of my greatest joys at IBM is showing customers how they can use IBM solutions to solve problems and improve their business. A common problem we hear is that enterprise clients need to run their apps locally, while leveraging the value of the cloud. In general they want to keep sensitive data local while integrating cloud benefits such as rapid deployment, continuous delivery, and microservices, and they want this to include Java applications.
Recently we released IBM Cloud private, a Kubernetes-based private cloud, which runs in your data center. You can start small, manage it yourself, and grow it to run whatever workloads you want. IBM Cloud private provides key runtimes and services that you depend on, such as Liberty, Db2, MQ, Microservice Builder, Redis, and much more. (learn more here).
In this article, I will show how we stood up our private cloud, and used this private cloud to deploy a stock trader application. This stock trader application is a Java microservices app that is running in Liberty, uses Db2, MQ, and Redis, and can also connect to a public cloud.
Here is a quick video summarizing what we built that will provide context for the rest of this article.
My hope is that you can repeat our success by following what we did, and if you have any questions, feel free to join the conversation in the comments.
The Architecture
We set out to develop a stock trader application that would run using local data, yet connect to the public cloud to get stock quotes and post messages when a customer’s loyalty level changed….a true Hybrid solution. We needed a database, a messaging queue, and a local cache. We also wanted the ability to continuously make code changes and update only what was needed. The result was an application architecture shown in Figure 1.
Figure 1: Application architecture including GitHub Enterprise and Microservice Builder to support continuous delivery goals
With that in mind, we then architected what our private cloud should look like. The results of this is shown in Figure 2.
Figure 2: Cloud layout, including DSM to help manage the database, and four VMs to run our cloud.
I cannot stress enough how important this layout step is. As you will see, there is a lot of communication that is required between the developer and the cloud administrator. The alignment between app and cloud architecture is essential to ensure that the solution meets the need of both parties.
The Plan
Our plan was straight-forward:
Set up IBM Cloud private
Set up the services that we needed
Add secrets to improve developer productivity
Run the application in IBM Cloud private
Integrate with Microservice Builder
Continuously deliver!
To truly understand what our clients would experience, we decided to role-play the personas we were designing for: Todd the cloud admin, and Jane the enterprise developer. In the end, this was a fantastic way to ensure that we could realistically prepare all aspects of the stock trader solution.
Setting Up IBM Cloud private
The first thing we did was set up IBM Cloud private. We followed the detailed instructions here. We got pretty good at it so now we can do it in about 1.5 hours. As you follow these instructions, here are a couple of tips:
Use the same node as both Master and Boot.
When you set up your SSH keys across your nodes, run the commands from the master node to itself.
If your VMs are running on different subnets, add the following line to your config.yaml:
calico_ipip_enabled: true
Once the IBM Cloud private environment was installed, we took a breath and opened the IBM Cloud private UI (Figure 3).
Figure 3: Manage the apps, storage, network, and compute nodes from this operations UI.
Figure 4: Kubernetes Dashboard UI, an opensource UI provided by Kubernetes
Our next step was to install each service that we needed: Db2, MQ, and Redis.
Seting Up Services
When I talked with our developer, we wanted to incrementally move into IBM Cloud private. Why? Well, there are many variables so if we could just try one thing, make it work, then try the next thing, we ended up achieving our goal faster than setting up the whole solution and hope it “just worked”.
For example, we wanted to test out the services before he moved his application into IBM Cloud private. Kubernetes nicely supports that by offering two ways to network into a service: Internally through “ClusterIP”, and externally through the proxy server using “NodePort”. Take a look at our MQ service in Figure 5:
Figure 5: the `kubectl describe` command showing service details
You will see an internal port 1414 only accessible inside the Kubernetes cluster by using the default-mq-mq:1414, and a NodePort 31966 that is available outside the private cloud using proxyNodeIPaddress:31966.
As a result, our developer could access MQ from his running code (basically changing one variable) and we could confirm that the services worked great. Then, once the app was using all services from the developer’s workstation, we added secrets and moved his app inside the private cloud.
OK, now we actually set up the services.
Setting Up DB2
Thanks to a handy recipe, installing DB2 was easy:
Once Db2 was running, we had to prime the database with the tables that the app needed.
Since Db2 installs automatically with a database called ‘sample’. We then added a ‘Stock’ and ‘Portfolio’ table to this database. We also added a configuration option that automatically deleted all rows in the Stock table that referenced deleted row in the Portfolio table. That way, the code didn’t have to iterate over each stock for a portfolio and delete it, prior to deleting the portfolio itself.
These are the commands we ran. We could have run this command from the DB2 command line: “db2 -tf createTables.ddl” but we installed DSM, so we ran these as SQL statements in DSM:
CREATE TABLE Portfolio(owner VARCHAR(32) NOT NULL, total DOUBLE, loyalty VARCHAR(8), PRIMARY KEY(owner));
CREATE TABLE Stock(owner VARCHAR(32) NOT NULL, symbol VARCHAR(8) NOT NULL, shares INTEGER, price DOUBLE, total DOUBLE, dateQuoted DATE, FOREIGN KEY (owner) REFERENCES Portfolio(owner) ON DELETE CASCADE, PRIMARY KEY(owner, symbol));
To verify it’s all working, we connected DSM to our DB2 database (Figure 6)
Figure 6: DSM lets you monitor multiple databases, run SQL statements, and view the database content through the Administer menu.
We could also verify that our Db2 setup is successful by running the following SQL statement:
SELECT * FROM Employee
Eventually, once our stock trader app was running, we replaced Employee, a table in the Sample database, with Portfolio, our table with our private data.
Once MQ was running, we needed to create the message queue that the app expected. I logged into the MQ UI and created a queue called, ‘NotificationQ’ (Figure 7)
Figure 7: Create the NotificationQ
Next, we had to authorize the app user ID ‘app’ to the queue. The MQ instructions said NOT to use the default admin ID, but to use the default application ID, ‘app’.
When you add ‘app’, it will show the group name as ‘mqclient’. From the MQI section, select the Browse, Get, and Put options (Figure 8).
Figure 8: ‘mqclient’ was added with the correct authority to browse, get, and put.
Setting Up Redis
To set up redis, we used the Redis app located in the IBM Cloud private App Center.
First, log into the IBM Cloud private UI: https://masternodeIP:8443/#/dashboard/ with the default user ID and password set to admin/admin. Once logged in, select the left menu and then “App Center”. Find Redis, and install it.
Setting Up API Connect and Quandl
As you’ve seen in past blogs, this stock trader app is built from earlier editions that use API Connect in IBM’s public cloud to then call Quandl. This version does not require API Connect, but if you want to learn more, and read how we’re calling Quandl to get stock quotes, read about it here.
Setting Up OpenWhisk and Slack Messaging
Another capability we built from previous editions of the stock trader application was to call an OpenWhisk action that sends a slack message. To get that portion working, you’ll want to read about it here.
Creating secrets
We have a recipe describing why secrets are so useful, and you can read it here. In a nutshell they make your application portable by letting you define custom, cloud-specific information regarding how the app can use each service.
Here are the secrets that we created for our stock trader application.
MQ Secret
First, we found the MQ service name
kubectl get svc
Then viewed the properties
kubectl describe service default-mq-mq
If you set up the services with NodePort, two ports will appear for internal and external access to the application. And another two ports for the UI. By default, port 1414 is what the application uses when the app is running inside the private cloud.
This Redis secret should actually be called, “the stock quote microservice secret” because it contains details to access Redis, as well as details to access Quandl, a provider of stock quotes. We found we could call Quandl 50 times per day without registering, or if we registered (no cost), it bumped that up to 300 calls per day (To register for Quandl, see http://quandl.com/ ).
We ran this to find the Redis service name
kubectl get svc
Then viewed the properties
kubectl describe service worn-horse-redis
To create the secret that the application can use, we needed to get the Redis password secret that the Redis install already created, and then add it into the secret our developer would use. Here’s what we used to set a password parameter in Kubernetes:
Finally, we created this secret (using the password parameter, service name, port, and our quandl key. If you don’t want to register, just leave the quandl-key field empty):
At this point, we decided to test the application inside IBM Cloud private (and you can too). Why? Because our code was in Eclipse on our developer’s laptop, and it was the next incremental step to build containers and then deploy them into IBM Cloud private. For us, it was a whole additional set of variables to move our code into GitHub and connect to our private cloud through Microservice Builder that we were not ready for yet (We’ll walk through how to do that next)
The proxy IP is the IP address of the VM acting as proxy node. The ‘traderPort’ is the external NodePort, and can be found using the same commands as above.
We ran this to find the Redis service name
kubectl get svc
Then viewed the properties
kubectl describe service trader-service
Make sure you use the NodePort, usually in the 30000 range.
Integrating with Microservice Builder
You may be asking, “I have the app running now, why bother with Microservice Builder”? For us, while it was tedious to set up Microservice Builder, we found that integrating with Microservice Builder saved us an amazing amount of time!
If you want to continuously deliver and enhance your app’s micro-services, you should use Microservice Builder. Our experience was that whenever we wanted to tweak a behavior, we could just change the code in GitHub, commit the changes, and…PRESTO, Microservice Builder would detect the changes, build them, and deploy updated containers into our private cloud.(Figure 9 and 10).
Figure 9: Micro-services are being built
Figure 10: Microservices are built successfully.
To start, follow the instructions to install Microservice Builder here. Read it closely. There are many manual steps around authenticating the Microservice Builder pipeline with GitHub that you need to pay attention to:
To be honest, we followed these instructions and still had problems. Here are a few tips that might help to reduce these problems for you:
Make the GitHub repos public. Microservice Builder does not work with private repositories.
Configure IBM Cloud private so that pods can access the private Docker image registry when deploying. We missed the fact in the article and took quite some time to realize it.
Add your entire team as “admins” when setting up Microservice Builder. We found it was difficult to add people after deployment.
In section 4 of the steps, the instructions mentions adding single quotes around the “Master.JavaOpts” field setting. Don’t do that. This instruction is old (it’s being updated, but not changed yet). Just keep it as it is.
Finally, if you are going to try Microservice Builder with your own code, here are some tips:
Use Maven to build. We had experience with Gradle, so needed to switch to Maven.
Using the command “bx dev” added the proper files to your GitHub repo so Microservice Builder knows what to do with the code.
Move your deployment.yaml into the manifest folder.
Stock Trader In Action — Through Microservices
Now lets take a peek at how we found value with all of this running. You can refer back to Figure 1 to see the application architecture. Here’s a screen shot of the trader web UI (Figure 11)
Figure 11: Stock trader app rendered from the ‘trader’ micro-service
From a web browser we connected to the “trader” micro-service that renders the simple web app. While it’s quite basic, we did want to change a few things and since it is a small micro-service, we could redeploy updates to the “trader” UI in seconds. Further, since Kubernetes handled the networking, we didn’t have to worry about changing IP addresses or DNS changes ourselves.
Another big time-saver was using the Liberty “Datasource” in the portfolio micro-service. This allowed us to switch out completely different databases (even switch between DB2, Oracle, sqlServer, etc.). All we had to do was update the db2 secret, restart portfolio, and it connected where we wanted to
As you add stock to a portfolio, the Stock Quote micro-service is contacted. It checks Redis to see if there is a local cache that is within 24 hours old, and if not, connects to quandl.com to fetch the latest stock quote. Once the portfolio is updated, the Loyalty Level micro-service is contacted which calculates if the user has reached the next level. In this case the Loyalty Level microservice determines I’ve achieved “Gold” level, so it sends a message to MQ.
As soon as the message is added to NotificationQ, the “Notification” micro-service notices it, calls OpenWhisk to trigger a message in our Slack channel. This is a great example of how a private cloud app can utilize a public cloud service while the sensitive data (the portfolio details) stays local.
Summary
We learned so much building this stock trader application. I encourage you to try it yourself, or even parts of it. In addition to the video overview, take advantage of the recipes (Db2, MQ, Secrets), and if you want to run our stock trader app (or fork it and start making changes), access it here:
I just got an email from Caribou Coffee, and unless it starts with BO and ends with GO, I usually quickly delete them. However, something about the “Uncover our Journey” title intrigued me, so I clicked (full disclosure: I’ve love Caribou Coffee ever since my first napkin had the saying, “Rich and Smooth…because Burnt and Bitter was already taken”).
What I discovered was an amazing way to communicate integrity, passion, character, deep technical detail, and the ability to execute on a vision through thoughtful design.
I think we could all learn from this (especially those of us in technology).
Transparency At first glance it looks like a play on words…”see through label?” but right away the site shows its transparency: “Oh, they’re going “open kimono” to show they are proud of their journey and want to share every detail (even the imperfections)
Detail in Design Maybe I’m reading too much into it, but as you scroll to “Our Clean Label Journey”, I noticed three things:
Mouse-over detail: behind the cute marketing message because they know it takes more than shallow words to convince a skeptic…and at this point in the world, I think we are all skeptics of anything
Scroll-Right is optional: They offer details with a scroll-right (or swipe left) to learn every step of their journey
The Scroll Bar Reflects Reality…that Their journey is NOT DONE: I love this part. The design shows a scrollbar … nice big fat scrollbar…and look what happens as you scroll right…it stops before the rail ends. Subtly they are showing that the journey isn’t done yet.
Off-Limits As you continue scrolling, you see the “Off-Limits” list where they again have cute slogans with fairly meaty details available for those that mouse over the content
No Guess-Work This was another favorite: “Guess What Might Be Added To Other Coffee” section let the user simply scroll and as a whimsical surprise, a very large technical list of ingredients appears on the right. Now, they could have added it in the main space, but how boring!
This was pure design delight. I could see the technical details, and even chuckled when commentary flowed in the list AND the bottom of the page “Almost there…” and so on.
Finally when the list is done, some very subtle yet effective animation throws the “Other” cup aside, and makes the Caribou cup glisten…like it won…but also like it sparkles with purity.
No Detail is Too Detailed In the menu section there’s a lot of pretty pictures with big words for the main ingredients. Only the most nerdy would scroll through the end of each ingredient list. If you do, then you’re like me and you’ll be further delighted with a “Detailed Ingredients” list that shows every last detail…and then a Culinary Team Note clarifying that even complicated sounding ingredients can be natural.
Finally, there’s a FAQ section that further shows honesty where they list exactly the drinks that are not Clean Label…and what ingredients aren’t, and a nice section on “This sounds complicated…how can it be natural?”
Well done, Caribou. I love the design…and the honesty. Shows you are a great company that cares about its users.
I music directed Rock Of Ages at Rochester Civic Theatre from July-October 2016 (vocal director, music director, led the band during the run). The lead-off song had a ripping guitar solo. This is a picture of the two of us down stage sharing the spotlight, and that exact moment, it was Remi’s turn to shine.
What I love about this is my look of joy and delight (with a hint of “Damn, he’s good!”) watching him in the spotlight. Certainly I could have taken all the “fun solos”, but I love to see those I’m leading SHINE…do what they’re great at and watch…and smile.
I love that smile in the photo. To me it says…
…we are better as a team contributing all our expert skills complimenting each other rather than fighting for the spotlight. I mean, I could have just been focused on my next part, ignoring his contribution…but (at least the photo suggests) I was thoroughly enjoying what this team member was doing and put the spotlight appropriately on him.
…the best team starts with preparation. I started in January practicing myself, getting organized, and spent most of the time building the best team possible…members with skills that outshine my own…that compliment each other…where the players are also nice…fun to be around.
…a great team truly listens to each other. In this show, there were times we acted as a single organism…completely in synch, and when a glitch happened (vocalist or my miscue) the band didn’t miss a beat…we adjusted and locked in without the audience even noticing….most of the time without even looking at each other…just sensing through a guitar lick, a hand wave, or a drum fill, what the next note should be.
…this great team’s suggestions were valued and many times taken.
…I know we spent endless hours rehearsing and preparing but LOOK AT YOU!! You are killing it!!
…when it came to the performance, they followed my lead. My hope was to gain their trust through rehearsal so that by communicating my vision early, taking and executing their suggestions, that by showtime there was zero hesitation or argument about the real-time directions I gave. The result was hard-hitting, locked-in rock-n-roll that showed not only our individual skills, but showed the elevated “one-ness” of the band in the “this sounds amazing and much more than the sum of its parts” kind of band.
Finally, to me, it says, “you are at your best when you focus on helping others succeed, not when you are striving for your own success”. I know, not very ‘career-driven’, but maybe that’s why in IBM-world I am happiest leading a project where the team has a common vision, where the designers and developers looked to me for direction, but (hopefully) know my main purpose is, through delivering an experience customers love, that each designer and developer have a deep ownership that results in a rich sense of satisfaction when their designs and code are the reason that outstanding experience exists in the first place.
With that kind of success…a product they can feel proud of, I think the teams, like the Rock of Ages band, can forever point to that period in their life and instead of remembering the long hours and demands of a selfish leader, instead think, “Remember that experience we delivered!?! They LOVED IT! I was an important part of that team. What a great time of my life and I’d be a part of that team again in a heartbeat”
Come on, you remember. You’re in high school. You are riding on the bus (or the back seat of your friends car), and the vehicle makes a sharp turn. Etiquette says you fight against the G-forces to keep in your space. But sometimes physics takes over and you lean hard into the person next to you.
If the person next to you is a pretty girl, it becomes an “opportunity curve”…
…a chance to get close to someone who is way out of your league
…a chance to say, “Sorry…the curve was sharp”
…and if you’re lucky, a chance to hear, “That’s OK. It was nice”
There are all kinds of forces that affect us every day. Most of them we naturally resist…it’s what etiquette suggests. Etiquette says it’s not proper to let that force push you…to be pushed into something you can’t control or foresee. Etiquette says you must always be in control.
…but what if etiquette is wrong?
What if etiquette is restricting an amazing journey that could be wonderful…life changing…terrifying…and beautiful all at the same time?
What if…the force isn’t something pushing against you…what if the force is something pushing for you into a dream-making opportunity that could only happen if a greater-than-you-could-muster-on-your-own force helped make it happen?
What if the force is the gentle presence of God guiding you, a divine nudge into your next-best-of-all-possible-multi-verses, and all you have to do is trust that this G-force always has your best interest in mind?
How about this: The next time a force guides us into a direction we aren’t in control of, lets…
…let go
…see what happens
…embrace the challenge/change/discomfort/awkwardness
…smile, take a deep breath, and yell, “OPPORTUNITY CURVE!!!”
While I’m way into music, I still found myself immersed in this little Google Doodle…enjoying the music, the story, and rooting for a cartoon character I was just introduced to seconds ago. For others not as familiar with his music, they learned that he composed music they recognized but didn’t know who wrote it…and even learned some sheet music structure as well!
Through it all, the Google Doodle inspired me by telling a story, complete with showing problems, sadness, and finally, resolution with resounding 9th symphony chorus. Most importantly, it made me want to continue to the end…to learn more, to stay curious for the outcome.
Think about it: “Inspired”…”Stay Curious”; quite an accomplishment from a silly little web app.
I just gotta wonder how much more our users would get out of our IBM Cloud content if we focused on those two phrases: “Inspire” and “Stay Curious”. What if we were driven to inspire by telling a story, educating with exercises along the way, and use emotion and success to keep users experimenting…to stay curious?
What if we made our documentation an actual reason to click to IBM Cloud? What if the experience of our DOCs was so satisfying, so sticky, so valuable, that the natural next step was to actually try the product out?
…and what if our DOCs were so intertwined with our product that after our users were educated, entertained, inspired, and guided, only then would they realize that through their curiosity, they’ve been using our product all along?
Thanks, Google, for a great lesson.
Here’s to inspiring users…
Here’s to helping users stay curious…
Here’s to creating the best cloud experience imaginable!
It was the announcement that IBM Systems Director, the product I spent years working on, was officially being pulled from market.
From 2004 through 2012 I spent most of my time at work working with users, designing, leading, educating, writing, and traveling to make IBM Systems Director the best it could be.
…and now it’s gone.
Not that it shouldn’t be…it’s a product from another era…pre-cloud. It’s purpose was to provide IT administrators a single experience that could manage the whole data center in a company’s shop. Certainly we can talk for hours about to what degree it succeeded doing that. While some may have criticized it, I loved working with a fantastic development team, and I felt like through our work with users and focusing on what they need, we were able to raise it a whole grade (or two) compared to what it could have been.
But, in the end, customers, and IBM, moved on.
What really messed me up is trying to think of all the personal and family sacrifice I made to make it better, not to mention the hit to the ego. I started to think of the missed family activities, all the effort, all the “we’ll fix it next release”, and it hit home that nothing…especially nothing in the IT world…lasts.
Which makes me think: what will last? In a big company like IBM, even the best employee leaves a hole that fills in within a week or two. It reminds me of a Diary Queen shake: A new employee is like taking a spoonful out of a melty shake…the melty ice-cream quickly folds in and within minutes, nobody knows the spoon was even in there. Even a stellar employee is like a spoon getting pulled out of a thick custard shake…it may take a bit longer but soon enough even the biggest hole gets filled in. Actually, a healthy company is designed to do that so productivity isn’t impacted by one person.
So where does that leave me?
When I boil it down, most things I just lift right out: Church, worship band, work, hobbies…
So what’s left? Relationships. My relationships to my family and friends. Most of my work relationships won’t last…hopefully some will but most are merely acquaintances (who will hopefully one day pause a few minutes before claiming my chair, monitor, and white-board markers). My family relationships are what might last: My wife, my kids. My wife I love dearly, and we are each-other’s anchor. But really the only thing that I am uniquely essential to is my kids. Sure someone else can raise them, but they won’t be their dad. That’s all me.
So what do I do with that? In a way it’s invigorating! It helps me focus on what’s actually important.
…to raise these kids the best I know how…
…to show them what hard work looks like
…that sometimes responsibility DOES mean sacrifice
…that a career is the HOW to provide and have a fantastic life, but not the WHY
…that life doesn’t revolve around them, but in how they can serve others
…that they should be driven by their passions and a career can possibly become that passion but will more likely their passion will become a wonderful side-car to their career that will give their life a sparkle.
…that they don’t forget what is most precious…it’s the WHO’s in your life, not the WHATs
Anyway, I’m still learning and trying to balance how this all works. Maybe I can teach and guide them so it doesn’t take them 23 years of hard work, where 8 of those years were entirely focused on a product that is no longer in the market…just to realize that the product’s purpose for me was to enable a fantastic life…it’s not the source of a fantastic life.
My sons are drummers. One is a killer-good drummer who can riff in a drum-line or a kit all day long. The other is just starting out, but already lays down a groove that compels me to pick up a guitar and jam along with him.
They just make me want to play with them…because they make me sound better.
Well, now I know why. Their teacher just published three drumming books (Get them…you’ll love them). The forward of the third book is so inspiring I think we all could learn from it in how we work with our team at work, how we approach our designs, and ultimately how we can delight our users.
Especially the last line:
“What actually makes drummers of great value in the professional world is not the amount of fills they know but rather their ability to make the rest of the band sound as good as possible”
Imagine: While a drummer has the ability to be the loudest one in the group, the most impressive (selfish?), the most showy, what Alec shows is that by serving the band and letting them shine, you will actually be the most valued and sought-out drummer of anyone.
What could it be like if we used all our talents and skills solely to make the rest of our ‘band’ sound as good as possible, rather than to make ourselves look good? How motivated would our teams be? How focused would our designs be? How great will our user’s experience be…because we are serving them, not furthering our own agenda/portfolio?
Do me a favor: As you read the image below, replace “drummer” with “designer”, “leader”, “general manager”, or heck, even “dad”.
After you read it, list below who your ‘band’ is. your family? your team at work? IT administrators? Developers? A youth group? Your users who are skeptical of any software because they’ve been burned in the past? Then, describe what you could do to make the rest of your band sound as good as possible.
I love guitar. I love playing it, recording it, composing with it, and reading about it.
…and I love how it can apply to design.
In a recent issue of Premier Guitar magazine, an article on Judas Priest focused on how they’ve thrived over the years and what it was like bringing on a new guitar player after playing with their last one for decades.
This quote:
“When somebody comes in and sees it in a different way, let them go with it for a minute. Live with it. You never know whether you’re going to like it or not. If you don’t, you can always go back to what it was”
It’s a great lesson for both new designers coming on board and experienced designers welcoming them.
Experienced designers need to embrace change, welcome new ideas, and new directions. Welcome your awesome designers’ ideas, passion, energy and run with them for a while. See how the ideas breathe and interact with your vision. Maybe your vision needs changing.
New designers need to understand the story, the history, where the product has been and how its customers interact with it. In Judas Priest’s case, they had loyal fans but also wanted new fans. They didn’t want to stay a tired “back in their glory days” band.
The combination of new designers paired with experienced designers can produce powerful results through a collaborative exchange of ideas, old and new, that might surprise your customers and make for an even more delightful experience.
When we designers at IBM start communicating ideas for a new design, one powerful way is through an analogy. It’s a way to relate a powerful capability and user value of complex enterprise software by associating it with something that everybody 10 years or older can understand.
“Our cloud?…it’s kinda like Disney World for your workloads”
But sometimes analogies are great to communicate how crappy software can be. Like this…
“Bad messages in your software is kinda like finding dog hairs in your cupcake.”
Mmmm…yummy…and thoughtful.
Cupcakes are delicious, beautiful, and everybody likes them. We want our software to be the same! The problem is that your software could be the most functionally rich, best designed, and beautiful UI in the world…but if bad messages appear, it wrecks the whole experience…frustrates your users, and sometimes makes them angry enough to make your users abandon your product.
It just happened to me.
Recently I watched my son register to automatically submit his transcripts to the university he was applying to. Great! Very useful! Love it!
When he signed up, here’s the message he got:
We tried other emails and it worked fine. We copy/pasted and all the other tricks (thinking it had hidden characters somewhere) but no luck. Finally, beyond frustration, we just gave up and contacted the guidance counselor the next day.
Days later, we learned that the email was not valid for registration because his school had ALREADY REGISTERED HIM!
While it’s technically accurate that the email is not valid during registration because the email was already registered, it’s a stupid message! It caused us endless grief and prompted us to use the ‘old fashioned’ way and abandon the software.
In the end, a user experience is only as delightful as its weakest message. Designing for error paths and writing great messages is boring. I get that. Most of us leave it to the end. But if we DO focus on messages just as much as the colors and fonts of a product, it could have a far deeper impact for our users.
How about you? Have you been delighted by a products messages? Or did you eat dog hair, too?
