UX – A Conversational System

Back to Listing

Ryan Russell-Yates

Hanover, MD, 03 March 2016


I’ve been tossing around the idea of improving the User Experience of SIMP. Part of that process has been trying to decide what that actually means. I believe good UX is really about trust. We start to trust ideas based on conversation about them. I believe the best user experience would come from a conversational system.

A few key pieces of what makes a conversational system: Do we speak the same language? Do I trust you’ll carry out what I expect to happen? Will you return information to me in this dialogue? Can I trust you with my secrets?

I think a system and a user speaking the same language is an integral part of trust. Sometimes two applications do something similar, but a user is more likely to trust the simplest and most concise verbiage. LDAP is a wonderful example of nebulous trust. Let’s examine adding a user:

# cat adam.ldif
dn: uid=adam,ou=users,dc=tgs,dc=com
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
cn: adam
uid: adam
uidNumber: 16859
gidNumber: 100
homeDirectory: /home/adam
loginShell: /bin/bash
gecos: adam
userPassword: {crypt}x
shadowLastChange: 0
shadowMax: 0
shadowWarning: 0
ldapadd -x -W -D "cn=ramesh,dc=tgs,dc=com" -f adam.ldif

Now, if I was adding a local account on a Linux system:

useradd adam

Intrinsically, we’re much more likely to trust useradd. I’d be much less likely to double check or be unsure if that user was added in comparison to LDAP. The LDAP has it’s own merits as well, describing our user, categorizing our user, and giving out a home directory and login shell in a centralized location. There are useradd flags that can also set some things such as shell and home location, but the more simple the command, the more faith we have in it. In a lot of cases though, simple commands aren’t feasible.

Once we share a mutual language with a system, we expect it to respond in a repeatable way. Puppet actually does an exceptionally good job of this in my mind. file {‘/usr/local/file’: ensure => present} places the file /usr/local/file on any operating system. This is expected behavior, and a great example of “Just do what I expect.” This holds true for expected conventions. If I made a program where the icon for save was a CD-ROM and the icon for load was a floppy disk, users would likely have very little faith in the save and load functions of the program, due to accepted language and conventions. Not only would the user not trust the save/load functions, but they may have less faith in the system overall due to the breach in trust. SIMP does a good job of this inside of the framework now in my mind, with things such as the SIMP iptables module being very straight forward and repeatable on a module or profile basis.

We also naturally like “interactive” systems. If I hit that save icon, I like a small notification that says “Saved.” On back-end systems, we like verbose and useful logging. One of my chief complaints with systemd is journalctl, which I feel gives me less information than “service” used too. Whether or not it’s true is hard to say, but I definitely feel that way. A step further, if a system is built to tell a user “Here is how I work, and here is how to use me” in a native language, that user is more likely to appreciate that experience. Users tend to appreciate a walk-through far more than a standard user guide. A system that can guide users through it’s use while asking questions in return makes lifelong supporters of a system. I think the most necessary piece of a conversational system is switching from the mindset of UX being a monologue to a dialogue. Going forward, I hope to see SIMP guide our users through some of the puppet framework, instructing them how to write small snippets of code that do things such as relax firewall rules and allow shell access to users. Most importantly, I’d like SIMP to tell users why this works, rather than just stating that it works.

Finally, we like to know that our data is safe. We universally know that a username and password on a system is designed to tell a system not to let others act in our stead. We strive to trust that the data we enter and the actions we take will be protected by our username and password in systems. When we see HTTPS, we trust that our information is encrypted from sender to receiver, and that someone has verified the owner of the website. In a system that works with security, it’s integral to inform the users what will be done with the security-related data that is collected. In SIMP, if you ask me what my client_nets are and ensure me that it will be used to tell the framework to give less trust to IP addresses outside the range, I grow to appreciate the client_nets global catalyst. A conversational system should tell you what it intends on doing with the security data it collects.

We have a ways to go to achieve a fully conversational system in my mind, but I believe it’s very doable. It has to be a UX mindset when building features and modules, and users who can build trust with a conversational system will be lifelong users and even contributors.

Sources

This ldap example was taken from: http://www.thegeekstuff.com/2015/02/openldap-add-users-groups/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+TheGeekStuff+(The+Geek+Stuff)

At Onyx Point, our engineers focus on Security, System Administration, Automation, Dataflow, and DevOps consulting for government and commercial clients. We offer professional services for Puppet, RedHat, SIMP, NiFi, GitLab, and the other solutions in place that keep your systems running securely and efficiently. We offer Open Source Software support and Engineering and Consulting services through GSA IT Schedule 70. As Open Source contributors and advocates, we encourage the use of FOSS products in Government as part of an overarching IT Efficiencies plan to reduce ongoing IT expenditures attributed to software licensing. Our support and contributions to Open Source, are just one of our many guiding principles

  • Customer First.
  • Security in All We Do.
  • Pursue Innovation with Integrity.
  • Communicate Openly and Respectfully.
  • Offer Your Talents, and Appreciate the Talents of Others

simp, ux, puppet

Share this story

We work with these Technologies + Partners

puppet
gitlab
simp
beaker
redhat
`
AFCEA
GitHub
FOSSFeb