There’s a four-year story behind my current design process, something I introduced last year on A List Apart—“Object-Oriented UX.” The approach advocates designing objects before actions. Now it’s time to get into the deeper benefits of OOUX and the smooth transition it can set up while shifting from object-based system design to interaction design.The “metaphor,” once found, is a perfectly definite thing: a collection of objects, actions on objects, and relationships between objects. Dave Collins, Designing Object-Oriented User Interfaces (1995)
Imagine you’re designing a social network that helps chefs trade recipes requiring exotic ingredients. With good ol’ fashioned research, you develop a solid persona (Pierre, the innovator-chef, working in a gourmet restaurant) and you confirm the space in the market. You understand the industry and the project goals. Now it’s time to put marker to whiteboard.
Where would you start designing?
Would you start by sketching out an engaging onboarding process for chefs? We do need chefs to make this thing successful—no chefs, no network! So maybe we start by making sure their first interaction is amazing.
Or maybe you start with one of the most frequent activities: how a chef posts a new recipe. And that could easily lead you to sketching the browsing experience—how will other chefs find new recipes?
Three or four years ago, I’d start by storyboarding a critical user path. I’d start with the doing.
Pre-OOUX, my initial design-thinking would look something like this. I’d figure out the interaction design while figuring out what a recipe actually should be.
I imagine many other user experience designers begin the same way, by designing how someone would use the thing. One interaction flow leads to the design of another interaction flow. Soon, you have a web of flows. Iterate on those flows, add some persistent navigation, and voilà!—you have a product design.
But there is a problem with this action-first approach. We are designing our actions without a clear picture of what is being acted on. It’s like the sentence, “Sally kicked.” We’ve got our subject (the user) and we’ve got our verb (the action). But where’s the object? Sally kicked what? The ball? Her brother? A brain-hungry zombie?
When we jump right into actions, we run the risk of designing a product with a fuzzy reflection of the user’s mental model. By clearly defining the objects in our users’ real-world problem domain, we can create more tangible and relatable user experiences.
These days, a lot happens before I begin sketching user flows (in this article, I use “user flow” and “interaction flow” interchangeably). I first define my user, asking, “Who’s Sally?” Next, I figure out her mental model, meaning all the things (objects) that the problem is made of, all the things she sees as part of the solution, and how they relate to one another. Finally, I design the interactions. Once I understand that Sally is a ninja armed with only a broomstick, and that she is faced with a team of zombies, I can better design the actions she’ll take.
In retrospect, I feel like I was doing my job backwards for the first two-thirds of my career, putting interaction flows before building an object-oriented framework. Now, I would figure out the system of chefs, recipes, and ingredients before worrying about the chef onboarding process or how exactly a chef posts a recipe. How do the objects relate to one another? What content elements comprise each object? Which objects make up my MVP and which objects can I fold in later? Finally, what actions does a user take on each object?
That’s what Object Oriented UX is all about—thinking in terms of objects before actions. In my previous article, we learned how to define objects and design a framework based on those objects. This time, we’re exploring how to smoothly transition from big-picture OOUX to interaction design by using a very simple tool: the CTA Inventory.What’s a CTA Inventory, and why is it important?
Calls to action (CTAs) are the main entry points to interaction flows. If an interaction flow is a conversation between the system and the user, the CTA is a user’s opening line to start that conversation. Once you have an object framework, you can add possible CTAs to your objects, basically putting a stake in the ground that says, “Interaction design might go here.” These stakes in the ground—the CTAs—can be captured using a CTA Inventory.
A CTA Inventory is a bridge from big-picture OOUX to detailed interaction design.
A CTA Inventory is just a fancy list of potential CTAs organized around your objects. Since most (all?) interactions involve creating, manipulating, or finding an object, we create this inventory by thinking about what a user wants to do in our system—specifically, what a user wants to do to objects in our system.
Creating a CTA Inventory does two things. First, it helps us shift gears between the holistic nature of system design to the more compartmentalized work of interaction design. Second, it helps us:
- think about interactions creatively;
- validate those interactions;
- and ultimately write project estimates with greater accuracy.
Let’s explore these three benefits a little more before creating our own CTA Inventory.Creative constraints improve brainstorming
Simply understanding your objects will help you determine the things that a user might do with them. We know that Sally wants to destroy zombies—but it’s only after we’ve figured out that these are the fast, smart, light-averting zombies that we can be prepared to design exactly how she’ll do it.
When we think about interactions in the context of an object, we give ourselves a structure for brainstorming. When we apply the constraints of the object framework, we’re likely to be more creative—and more likely to cover all of our bases. Brainstorm your actions object by object so that innovative features are less likely to fall through the cracks.
For example, let’s think about the object “ingredient” in our Chef Network app. What are all the things that Pierre might want to do to an ingredient?
- Mark the ingredient as a favorite.
- Claim he’s an expert on the ingredient.
- Add the ingredient to a shopping list.
- Check availability of the ingredient at local stores.
- Follow the ingredient to see new recipes that are posted using this ingredient.
- Add a tip for using this ingredient.
By using the object framework, I might uncover functionality I wouldn’t otherwise have considered if my brainstorming was too broad and unconstrained; structure gives creative thinking more support than amorphous product goals and squishy user objectives.Validate actions early
Good news. You can user-test your system of objects and the actions a user might take on them before spending long hours on interaction design. Create a prototype that simply lets users navigate from one object to another, exploring the framework (which is a significant user goal in itself). Through observation and interviews, see if your system resonates with their mental model. Do you have the right objects and do their relationships make sense? And are the right “buttons” on those objects?
Armed with a simple prototype of your interconnected objects and their associated CTAs, you now have a platform to discuss functionality with users—without all the hard work of prototyping the actual interactions. In a nutshell: talk to your users about the button before designing what happens when they click it.
Interaction design can be some of the most difficult, time-consuming, devil-in-the-details design work. I personally don’t want to sweat through designing a mechanism for following chefs, managing alerts from followed chefs, and determining how the dreaded unfollow will work…if it turns out users would rather follow ingredients.Estimate with interaction design in mind
As we’ve established, interaction design is a time- and resources-devouring monster. We have to design a conversation between the system and the user—an unpredictable user who requires us to think about error prevention, error handling, edge cases, animated transitions, and delicate microinteractions. Basically, all the details that ensure they don’t feel dumb or think that the system is dumb.
The amount and complexity of interaction design your product requires will critically impact your timeline, budget, and even staffing requirements, perhaps more than any other design factor. Armed with a CTA Inventory, you can feel confident knowing you have solid insight into the interaction design that will be handled by your team. You can forecast the coming storm and better prepare for it.
So, do you love this idea of better brainstorming, early validation, and estimating with better accuracy? Awesome! Let’s look at how to create your amazing CTA Inventory. First, we will discuss the low-fidelity initial pass (which is great to do collaboratively with your team). Next, we will set up a more formal and robust spreadsheet version.CTA Inventory: low-fidelity
If you haven’t read my primer on object mapping, now would be a great time to go and catch up! I walk you through my methodology for:
- extracting objects from product goals;
- defining object elements (like core content, metadata, and nested objects);
- and prioritizing elements.
The walk-through in the previous article results in an object map similar to this:
An object map before layering on a CTA Inventory.
I’ve used outlined blue stickies to represent objects; yellow stickies to represent core content; pink stickies to indicate metadata; and additional blue stickies to represent nested objects.
A low-fidelity CTA Inventory is quite literally an extension of the object mapping exercise; once you’ve prioritized your elements, switch gears and begin thinking about the CTAs that will associate with each object. I use green stickies for my CTAs (green for go!) and stack them on top of their object.
An object map with a quick, low-fidelity CTA Inventory tacked on. Potential CTAs are on green stickies placed next to each object.
This initial CTA brainstorming is great to do while workshopping with a cross-functional team. Get everyone’s ideas on how a user might act on the objects. You might end up with dozens of potential CTAs! In essence, you and your team will have a conversation about the features of the product, but within the helpful framework of objects and their CTAs. Essentially, you are taking that big, hairy process of determining features, then disguising it as a simple, fun, and collaborative activity: “All we’re doing is brainstorming what buttons need to go on our objects! That’s all! It’s easy!”
Each object might need roughly 10–15 minutes, so block out an hour or two to discuss CTAs if your system has three to five objects. You’ll be surprised at the wealth of ideas that emerge! You and your team will gain clarity about what your product should actually do, not to mention where you disagree (which is valuable in its own right).
In our chef example, something pretty interesting happened while the team was hashing out ideas. During the CTA conversation about “ingredient,” we thought that perhaps it would be useful if chefs could suggest a substitute ingredient (see circled green sticky below). “Fresh out of achiote paste? Try saffron instead!” But with that in mind, those “suggested substitute ingredients” need to become part of the ingredient object. So, we updated the object map to reflect that (circled blue sticky).
After brainstorming CTAs, we needed to add a nested object on “ingredient” for “ingredients that could be substituted.”
Although I always begin with my objects and their composition, CTA brainstorming tends to loop me back around to rethinking my objects. As always, be prepared to iterate!CTA Inventory: high-fidelity
CTAs can get complicated; how and when they display might be conditional on permissions, user types, or states of your object. Even in our simple example above, some CTAs will only be available to certain users.
For example, if I’m a chef on an instance of one of my own recipe objects, I will see “edit” and “delete” CTAs, but I might not be able to “favorite” my own recipe. Conversely, if I’m on another chef’s recipe, I won’t be able to edit or delete it, but I will definitely want the option to “favorite” it.
In the next iteration of our CTA Inventory, we move into a format that allows us to capture more complexities and conditions. After a first pass of collaborative, analogue brainstorming about CTAs, you might want to get down to business with a more formal, digitized CTA Inventory.
A detailed CTA Inventory for our chef network example. Dig in deeper on the actual Google Sheet.
Using a Google spreadsheet, I create a matrix (see above) that lets me capture thoughts about each object-derived CTA and the inevitable interaction flows for each one:
- Why do we even have this CTA? What’s the purpose, and what user or business goal does it ladder up to?
- Who will trigger this CTA? A certain persona or user type? Someone with a special permission or role?
- Where will the CTAs live? Where are the obvious places a user will trigger this interaction flow? And are there other creative places we should consider putting it, based on user needs?
- How much complexity is inherent in the interaction flow triggered by this CTA? This can help us estimate level of effort.
- What is the priority of this interaction flow? Is this critical to launch, slated for a later phase, or a concept that needs to be researched and validated?
- What questions and discussion points does this CTA raise?
Before you start designing the interactions associated with each of your CTAs, get comfortable with the answers to these questions. Build an object-oriented prototype and validate the mental model with users. Talk to them and make sure that you’ve included the right doorways to interaction. Then you will be perfectly positioned to start sketching and prototyping what happens when a user opens one of those doors.A solid foundation for designing functionality
You’ve collaboratively mapped out an elegant object-oriented design system and you’ve created a thorough CTA Inventory. You built a rough, clickable prototype of your system. With real users, you validated that the system is a breeze to navigate. Users pivot gracefully from object to object and the CTAs on those objects make sense for their needs. Life is good.
But OOUX and a CTA Inventory will not help you design the interactions themselves. You still have to do that hard work! Now, though, as you begin sketching out interaction flows, you can feel confident that the functionality you are designing is rooted in solid ground. Because your CTA Inventory is a prioritized, team-endorsed, IxD to-do list, you’ll be more proactive and organized than ever.
Most important, users getting things done within your system will feel as if they are manipulating tangible things. Interacting will feel less abstract, less fuzzy. As users create, favorite, add, remove, edit, move, and save, they will know what they’re doing—and what they’re doing it to. When you leverage an object-based CTA Inventory, your product designs and your design process will become more elegant, more streamlined, and more user-friendly.
We had the first MariaDB Berlin Meetup on Tuesday 12.04.2016 at the Wikimedia Berlin offices at 7pm. More or less there were over 54 people that attended the event, a mix of MariaDB Corporation employees and community members. We competed with the entertainment at the AWS Summit Berlin which was apparently about 400m away! Food and drink were enjoyed by all, and most importantly there were many, many lightning talks (minimum 5 minutes, maximum 10 minutes – most were about 6-7 minutes long).
The bonus of all of this? Lots and lots of slides for you to see. Grab them from the Google Drive folder MariaDB Berlin meetup April 2016.
- Monty talked about improving the speed of connections to MariaDB Server, some work he’s just pushed fairly recently to the 10.2 tree.
- Dipti spoke about MariaDB ColumnStore and it is now clear we’ll see some source/binary drop by the end of May 2016.
- Sergei Petrunia and Vicentiu Ciorbaru spoke about the upcoming window functions that MariaDB Server 10.2.0 will see (yes, the alpha should be out real soon now).
- Jan spoke about InnoDB in 10.2.
- Lixun Peng spoke about a fairly interesting feature, the idea to flashback via mysqlbinlog and how you can have a “Time Machine”. I can’t wait for flashback/time machine to appear in 10.2. The demo for this is extremely good.
- Kolbe spoke about data at rest encryption using the MariaDB Amazon AWS KMS plugin.
- Sanja and Georg went up together to speak about 10.2 protocol enhancements as well as what you’ll see in Connector/C 3.0.
- Wlad gave us a good rundown on authenticating with GSSAPI, something you will notice is also available in MariaDB Server 10.1’s later releases.
- Johan Wikman gave us an introduction to MariaDB MaxScale, which started off the talks on MaxScale.
- Markus talked about the readwritesplit plugin.
- Massimiliano went into the Binlog server.
- Martin didn’t use slides but gave us an amazing talk titled “Rival concepts of SQL Proxy”; it was very well given and I’ve encouraged him to write a blog post about it.
- Community member Ben Kochie, an SRE at SoundCloud gave us a quick talk on Monitoring MySQL with Prometheus and how much they depend on the PERFORMANCE_SCHEMA.
- Diego Dupin spoke a little about the MariaDB Java Connector, and the idea was to do a demo but the projector via HDMI seemed to be a bit wonky (this was also true of using my Mac; the VGA output however worked fine). So it was just a quick talk without any deck.
We ended with a quick Q&A session with Monty dominating it. Lots of interesting questions around why the name Maria, licensing thoughts, ensuring all the software we have are in distributions, etc. Some ended up going for pizza while others ended up in a hotel bar at the Crowne Plaza Potsdamer Platz — and the chatter went on till at least 11pm.
Thanks again to Georg Richter who found us the venue and also did a lot of the legwork with Wikimedia Foundation.
Do get started playing with MySQL Shell. If you’re using the yum repository, remember to ensure you have enabled the mysql-tools-preview in /etc/yum.repos.d/mysql-community.repo. And don’t forget to load the X Plugin in the server! I can’t wait for the rest of the blog posts in the series, and today just took a cursory look at all of this — kudos Team MySQL @ Oracle.
However, I’m concerned that the GA is getting what you would think of as more than just a maintenance release. We saw 5.7.11 get at rest data encryption for InnoDB, and now 5.7.12 getting even more changes. This is going to for example, ship in the next Ubuntu LTS, Xenial Xerus. Today it has 5.7.11, but presumably after release it will be upgrade to 5.7.12. I am not a huge fan of surprises in LTS releases (predictability over 5 years is a nice thing; this probably explains why I still have a 5.0.95 server running), but I guess this small band-aid is what we need to ensure this doesn’t happen going forward?
As for the other question I’ve seen via email from several folk so far: will MariaDB Server support this? I don’t see why not in the future, so why not file a Jira?
As promised, we delivered the OpenSTEM Digital Technologies Program for Primary Schools (F-6) to schools and individual teachers who already signed up: initial units for each year level, resource PDFs and activities, free software, a board game, optional incursions and workshops and other useful resources.
“Our goal is to make sure our students are at the cutting edge of innovation through the development of skills to become the technology architects of the digital age,” Queensland Premier Annastacia Palaszczuk said, “This will include an assessment of coding and computer science, as well as early stage robotics, something I firmly believe should be a part of our education system.”
— ‘Advance Queensland’ package announcement (July 2015)
Appreciating the very full schedule that teachers have, we have gone beyond regular integration with the initial materials for Digital Technologies (Australian Curriculum v8.1). Instead, the base fits directly within existing curricula, particularly Maths and English. So, doing the basics doesn’t cost any extra time!
That said, we also have some catching up to do. It’s no good tossing older students (or their teachers!) at more complicated problems when they don’t yet have the base level understanding or skills covered in the earlier years. So we have a catch up plan integral to our initial units.
Today’s students have been immersed in the stream of new technologies since they were born. They have much to learn, but they regard the technology itself as an entirely normal part of life and society.
To be able to guide the students, all educators now also need to go beyond using specific technologies to understanding how things work on a broader scale, and how it all fits together. So uniquely, the journey is very much a joint one and in some parts the teachers are learning along with (slightly ahead of) the students.
The more I see our teachers and students work with the programs, the more convinced I am that we have a great partnership and are doing the right thing by the kids.
— Cheryl Rowe, Principal
OpenSTEM’s related Robotics Program was recently featured on Channel TEN @ Schools coverage in Brisbane.
With schools already signed up and implementing this program in 2016, you can start any time and in a form that suits you (school wide, or individual teachers or year levels). Contact us for more details, and any questions you might have.
Feel free to ask us for a reference (teacher or principal of a school we’ve worked with).
I can't beleive I have to write this in 2016, more that twenty years after the bug in the DEC "Tulip" ethernet controller chip which created this mess.
There are only two ethernet speed and autonegotiation settings you should configure on a switch port or host:1.
Auto negotiation = on2.
Auto negotiation = off
Speed = 10Mbps
Duplex = half
These are the only two settings which work when the partner interface is set to autonegotiation = on.
If you are considering other settings then buy new hardware. It will work out cheaper.
That is all.But...
Oh, so you know what you are doing. You know that explicitly setting a speed or duplex implicitly disables autonegotiation and therefore you need to explicitly set the partner interface's speed and duplex as well.
But if you know all that then you also know the world is not a perfect place. Equipment breaks. Operating systems get reinstalled. And you've left a landmine there, waiting for an opportunity...
A goal of modern network and systems administration is to push down the cost of overhead. That means being ruthless with exceptions which store away trouble for the future.
I know a colleague who keeps a “wall of shame” for emails he gets from clients—moments of confusion on their end that (for better or worse) are also funny. The thing is, we know how to answer these questions because we’ve heard them all before: Why does this look different when I print it? How do people know to scroll? To a certain extent, making light of the usual “hard questions” is a way of blowing off steam—but it’s an attitude poisonous for an agency.
So, why do we disregard these humans that we interact with daily? Why do we condescend?
I think it’s because we’re “experts.”
As director of user experience at a digital agency, I’m prey to a particular kind of cognitive dissonance: I’m paid for my opinion; therefore, it should be right. After all, I’m hired as a specialist and therefore “prized” for my particular knowledge. Clients expect me to be right, which leads me to expect it, too. And that makes it difficult to hear anything that says otherwise.
As consultants, we tend to perceive feedback from a client as feedback on our turf—a non-designer giving direction on a design or a non-tech trying to speak tech. As humans, we tend to ignore information that challenges our beliefs.
This deafness to clients is akin to deafness to users, and equally detrimental. With users, traffic goes down as they abandon the site. With clients, the relationship becomes strained, acrimonious, and ultimately can endanger your livelihood. We wouldn’t dream of ignoring evidence from users, but we so readily turn a deaf ear to clients who interject, who dare to disrupt our rightness.
When a client hires us, they should come away with more than a website. They should gain a better understanding of how websites are designed, how they work, and what makes them succeed. We are the ones equipped to create this hospitable environment. For every touchpoint our clients have with us, we could be asking the same questions that we do of our users:
- How do clients interact with our products, e.g., a wireframe, design, or staging site?
- What knowledge do they have when they arrive, and what level must we help them reach?
- What are the common stumbling blocks on the way there?
Thinking back to our wall of shame, suddenly those cries of frustration from clients we’ve branded “difficult” are no longer so funny. Those are now kinks to change in our process; culture problems to address head-on; and product features that need an overhaul. In other words: from user experience, client experience. It means embracing “the uncomfortable luxury of changing your mind.”
I now go out of my way to look for these moments of client confusion, searching my inbox and Basecamp threads for words like “confused,” “can’t,” and “trouble.”
These examples are just a few pleas and complaints I’ve found along the way, plus the changes my agency has made as a result. It’s helped us revamp our workflow, team, and culture to enhance the “Blenderbox client experience.”Make deliverables easy to find “Hey guys…I’m having trouble figuring out which version of the white paper is the final version. Could someone attach it to this chain? Thanks.”
This one was easy. When we asked our clients about the problem—always the first step—we learned that they had trouble finding recent files when they saved deliverables locally. We were naming our files inconsistently, and (surprise!) that inconsistency was coming back at us in the form of confused clients.
I’ve seen this at every company I’ve been a part of, and it only gets worse outside the office; if you don’t believe me, go home tonight and look at your personal Documents folder. If I can’t keep my own filenames straight, how could we expect 20 of us to do it in unison? Clearly, we needed some rules.
Our first step was to bring uniformity to our naming structure. We had a tendency to start with the client’s name‚ which is of little use to them. Now, all deliverables at Blenderbox use this style:Blenderbox.ClientName.DocName.filetype
The other point of confusion was over which file was “final.” In the digital world, the label “final” is usually wishful thinking. Instead, the best bet is to append the date in the filename. (We found that more reliable than using the “last edited” date in a file’s metadata, which can be changed inadvertently when printing or opening a file.) Write dates in YMD format, so they sort chronologically.
Next came version control—or do we call that rounds, or sprints? Unfortunately, there’s no single answer for this, as it depends on whether a contract stipulates a fixed number of rounds or a more iterative process. We gave ourselves some variations to use, as necessary:
When a number of rounds is stipulated, the round number is appended. For Agile or other iterative projects, we use only the date. And when compiling months of iterative work (usually for documentation), we call it “Consolidated.” That’s as close to final as we can promise, and of course, that gets a date stamp as well.Show how details become the big picture “See the attached pic for a cut-and-paste layout”
Here, the client cut-and-pasted from our design to create their own. Why? It’s not because they were feeling creative. They had a variety of content and they wanted to know that every page on their site was accommodated by the design. Of course, we had already planned for every page, but we needed to better explain how websites work.
Websites are not magic, nor are they rocket science. We can teach clients at least the basics of how they work. When we step back and take the time to explain what we do, they better understand our role and the value we bring to their business, which results in happier clients and more work for us down the road.
Prompted by this particular client, we incorporated an explanation of reusable templates and modules right into our wireframes. On page one, we describe how they work and introduce an icon for each template. These icons then appear on every wireframe, telling the client which template is assigned to the page shown.
Since implementing this technique, we’ve seen our clients start talking more like us—that is, using the language of how websites work. With improved communication, better ideas come out of both sides. They also give feedback that is usable and precise, which makes for more efficient projects, and our clients feel like they’ve learned something.Compromise on comfort zone “can u please send over the pdf of it so we can print them out and show a&a? tx”
This is my favorite quote, and we hear this message over and over; clients want to print our deliverables. They want to hold them, pass them around, and write on them, and no iPad is going to take that away from them. Paper and pen are fun.
It’s a frustrating trend to lay out work on 11″×17″ paper, which is massive, beautiful, and only useful for designers and landscape artists. Who has a printer that size? Certainly not the nonprofits, educators, and cultural institutions we work with. So, we set about making our wireframes printable, and made for trusty 8.5″×11″.
Since no existing stencils would do, we made our own set (which you can download on our site).
We also fixed a flaw with common wireframe design that was confusing our clients: the notes. Go do an image search for “annotated wireframes.” Does anyone want to play “find the number on the right”?
Can you imagine assembling furniture this way? In our new layout, the notes point directly to what they mean. The screen is also smaller, deemphasizing distracting Latin text while giving primacy to the annotation. As a result, we find that our clients are more likely to read the notes themselves, which saves time we’d spend explaining functionality in meetings.Figure out the format “I know I am being dense, but I am finding myself still confused about the Arts Directory. How does that differ from the next two subsections?”
Here, a client was struggling (and rightly so) with a large set of designs that showed some small differences in navigation over multiple screens. By the end of the design phase, we often rack up a dozen or more screens to illustrate minor differences between templates, on-states, rollovers, different lengths of text, and the other variations that we try to plan for as designers. We also illustrate complex, multistep interactions by presenting a series of screens—somewhat like a flip book. Regardless of whether you present designs as flat files or prototypes, there are usually a few ways to enhance clarity.
If your designs are flat (that is, just image files) compile them into a PDF. This sounds obvious, but JPG designs require clients to scroll in their browser, and it’s easy to get lost that way. Because PDFs are paginated, it’s easier for clients to track their location and return to specific points. As a bonus, using the left and right arrows to flick through pages will keep repeated elements like the header visually in place. Another reason to use PDFs: some file types are less common than you’d think. For example, one government client of ours couldn’t even open PNG files on their work machine.
More and more, we’re using prototypes as our default for presenting designs. There is an astounding number of prototyping tools today (and choosing one is a separate article), but we’ve found that prototypes are best for explaining microinteractions, like how a mobile nav works. Even if you don’t have the time or need to demonstrate interactions, putting your designs in a prototype ensures that clients will view them right in their browser, and at the proper zoom level.Make time to celebrate
Clients shouldn’t be the “forgotten user.” We create great products for them by focusing on their end users—while forgetting that clients experience us twice over, meaning their user experience with the product and their user experience with us. Writing off a flustered client as out of touch means we’re disregarding our role as designers who think about real people. When these biases surface, they reveal things that we could be doing better. It’s shortsighted to think our roles make us infallible experts.
Searching client communications for keywords like “trouble” and other forms of subtle distress can help us identify moments of confusion that passed us by. It forces us to address problems that we didn’t know existed (or didn’t want to see). At Blenderbox, the results have been good for everyone. Our clients are more confident, receptive, and better educated, which empowers them to provide sharp, insightful feedback—which in turn helps our team design and build more efficiently. They’re happier, too, which has helped us gain their trust and earn more work and referrals.
We’re getting so desensitized to the word, but we all understand that there’s value in empathy. And, like any other ideal, we forget to practice it in the bustle of daily work. Because empathy is a formal part of UX, we don’t get to use the “busy” excuse. Even mundane design activities should be daily reminders to listen to the people around you, like a sticky note on your monitor to “Put yourself in their shoes.” In other words, we can’t overlook that our clients are people, too. When we stop and think about user experience, we might just be doing our job, but we’re also saying that we choose sensitivity to others as our primary professional mission. And that is the first step to making great things happen.
I have never been to Sofia, Bulgaria till this past February 2016, and boy did I enjoy myself. I visited the Bulgaria Web Summit and spoke there amongst many others. A few notes:
- Almost 800 people (so more than last year); hence the event was sold out
- Missed the RocksDB talk due to the massive Q&A session that went on afterwards.
- Very interesting messaging
- LinvoDB (embeddable MongoDB alternative) — LinvoDB / www.strem.io
- Use case: < 1 million objects (indexes are in memory using a binary search tree; so don’t use it for more). HTML5/Electron/NW.js. Best used with AngularJS/React and maybe Meteor. Can also use NativeScript or React Native. You can use it with node.js but its not recommended for server use cases.
- Works with SQLite or LevelDB (why not RocksDB yet?). Can also use with IndexedDB/LocalStorage
- Implemented almost entirely the MongoDB query language. Gives you automatic indexes.
- FTS in memory (linvodb-fts) – uses trie/metaphone modules for node.js. Can also do p2p replication, persistent indexes, compound indexes
I enjoyed speaking about MariaDB Server as always, and its clear that many people had a lot of questions about it. Slides. Video. It was tweeted that I had to answer questions for about as long as my talk, afterwards, and it was true :)
I got to meet Robert Nyman at the social event (small world, since he works at the office where Jonas of ex-MySQL fame does). Also met someone very interested in contributing to InfiniDB. It was nice having a beer with my current colleague Salle too. And speaking to the track moderator, Alexander Todorov was also a highlight – since we had many common topics, and he does an amazing amount of work around automation and QA. His blog is worth a read.