By Deane Barker on August 19, 2014
Linux-on-the-desktop pioneer Munich now considering a switch back to Windows: I remember writing about this often a decade ago. Sad to see that it hasn’t worked out, but I’ve long-maintained that Microsoft isn’t nearly as bad as it’s made out to be.
The world is still waiting for the year of Linux on the desktop, but in 2003 it looked as if that goal was within reach. Back then, the city of Munich announced plans to switch from Microsoft technology to Linux on 14,000 PCs belonging to the city’s municipal government. While the scheme suffered delays, it was completed in December 2013. There’s only been one small problem: users aren’t happy with the software, and the government isn’t happy with the price.
Though, towards the end of the article, things take on a tone of conspiracy. Not sure what to make of that.
By Deane Barker on August 19, 2014
Reading Literature on Screen: A Price for Convenience?: I was waiting for someone to do a study like this. The results confirm what I suspected, as I personally tend to rush more when reading something electronically.
A team of researchers led by Anne Mangen at the University of Stavanger in Norway and Jean-Luc Velay at Aix-Marseille Université in France divided 50 graduate students — with equivalent reading habits and experience with tablets — into two groups and had them read the same short story by Elizabeth George (in French translation). One group read the story in paperback, the other on an Amazon Kindle DX. All the while, researchers measured the students’ reading time and their “emotional response” — using a standard psychology scale — to the text. Afterward, they were tested extensively on different aspects of the story.
By Deane Barker on July 8, 2014
Scoop: A Glimpse Into the NYTimes CMS: The NY Times lifts the lid on its own CMS – entitled “Scoop” – to explain how it works and what it does. The article is brilliant: it explains a lot of the features in clear terms. Some notes:
- The system is clearly decoupled, and they explain why very well.
- They have field and field group level locking, so that editors can work on the same article at the same time.
- They publish 700 articles a day out of it.
- They’re using ICE, their own comment- and change-enhanced text editor, which they open-sourced.
If you love CMS, this is a great article. I think few companies share at this level because they don’t think anyone would be interested, but there’s a subculture of card-carrying CMS nerds that love this stuff
By Deane Barker on June 26, 2014
Uber isn’t the problem; taxi regulations are: This column for the Boston Globe (by John Sununu, of all people?) pulls no punches, and explains one of the problems faced by technological advancements in any field: they threaten the established status quo which someone is making money from.
Uber has plenty of enemies. The Web-based taxi service opened for business just five years ago, but recently its reputation has instilled enough fear in competitors to tie up traffic not just in Boston but in London, Paris, and a dozen other European cities. The protests staged were intended as a defiant stand by cabbies against the “unregulated” car service. Instead, they were an advertisement of a different sort: for outdated business models, archaic regulatory structures, and entrenched business interests that are desperately fighting to protect the status quo.
Indeed, what’s the argument against Uber? That it’s somehow worse than a traditional taxi? Or just that it’s unfair? If it’s unfair, do we need more regulation or less?
By Deane Barker on June 23, 2014
Online advertising effectiveness: For large brands, online ads may be worthless: A lot of startlingly honest revelations in here. Turns out that we have no idea if online advertising works, and it probably doesn’t.
[…] if somebody searches for “Amazon, banana slicer,” and clicks on a search ad that pops up right next to his results, chances are he would have made it to Amazon’s site without the extra nudge. Even if he never typed the word Amazon, he still might have gotten to the site through the natural power of search.
By Deane Barker on June 8, 2014
At some point, anyone working on the web has heard the exhortation that ideal web navigation should be “seven items, plus or minus two” with some vague reference to science which “proves” this is true.
Some years ago, I finally decided to look up the “science” and found that this is a reference to what’s been called “Miller’s Magic Number,” which come from an article by George Miller published in the Psychological Review in 1956. The article was entitled “The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information” (link to original text).
This weekend, I finally took the time to read the article. It’s dense, but in it, Miller summarizes dozens of studies that examine (1) the ability of humans to remember information, and (2) the ability of humans to distinguish between gradients of information (so, to evaluate something – an audio tone, in one example – and correctly categorize it). He summarizes the research to mean that our ability to do these things across all these different studies fell to somewhere around seven items.
I was bothered by what I found. The more I read both the article and multiple summaries of it, the more I became convinced that this has nothing to do with web navigation. It just didn’t seem to follow – I don’t memorize web navigation, nor do I compare it to a gradient scale. All the studies Miller discussed seem to do with recall and categorization. I couldn’t figure out what this had to do with anything.
I was all set to write a passionate post to his effect…and then I found that someone had beat me to it:
UX Myth #23: Choices should always be limited to 7+/-2
Limiting the number of menu tabs or the number of items in a dropdown list to the George Miller’s magic number 7 is a false constraint. Miller’s original theory argues that people can keep no more than 7 (plus or minus 2) items in their short-term memory. On a webpage, however, the information is visually present, people don’t have to memorize anything and therefore can easily manage broader choices.
That’s a well-written post that summarizes about a dozen references which refute the link between anything Miller ever did and the design of web UI and navigation.
Bottom line: the “magic number 7” has nothing to do with web navigation, and only may have some application to larger concepts of IA. If someone quotes it, they’re just likely just repeating something they’ve heard and have never actually read the primary research on it.
This is sadly common – things that make a good sound bite tend to take on a life of their own. We repeat these things because they sound smart and reinforce some narrative which makes sense in our heads. They provide form to an amorphous concept which we hope has discoverable boundaries, so when we find something that claims to define one such boundary, we pin our hopes on it and are loathe to let it go or even examine it too hard lest we threaten it. From there, these things propagate like a virus.
Larger lesson learned: make an effort to read and evaluate original sources, which I’ve argued in favor of before. If you hear something like this, trace it back to see whether the original research actually exists and whether or not it supports the conclusion.
By Deane Barker on June 1, 2014
Content management isn’t unique this in regard, but the CMS sales cycle is a process of people asking for things they’re never going to use. You smile and play along because they’ve put a lot of work into that RFP, but, honestly, at least 50% of the functionality they swear they need is nothing that’s ever going to get implemented. Call me a cynic.
This is never more true than with workflow. I’ll say this: workflow is the most over-purchased feature of content management, hands-down (I’ve said this before, in fact).
Seemingly every project has grand plans around workflow. Editors are going to submit content to an approver, then it’s going to an editorial committee of which 60% need to sign off, then it’s going to a metadata specialist, then the legal department, and then it will be published when the temperature in Moscow hits 60 degrees and the Oakland Raiders win the Superbowl, etc.
None of this ever happens (especially the part about the Raiders and the Superbowl…)
In my experience, 95% of “workflows” are simple serial chain approvals, and 95% of those are one step. Someone can edit and submit, then someone else comes to review then publish. It’s barely even “workflow,” but that’s fine because it works and it’s what most clients really need.
I wasn’t a huge fan of Ektron as a CMS, but as noted in the link above, they did workflow well as what they simply called “Approval Chains.” They didn’t even try to pretend that workflow was anything more than a chain of approvers, stacked however many levels deep.
EPiServer has a slightly less powerful model in that you can give Editor A “Edit” rights but not “Publish” rights. This means that Editor A can simply designate content as “Ready to Publish,” and Editor B (who has “Publish” rights) has to come along and publish it. Same thing, really – a simple approval chain, but only one level deep.
Over the years, I’ve come to understand, that when a client says they need “workflow,” what they’re most likely talking about is “collaboration.” They don’t want approvals so much as they want to be able to communicate with other editors about content and make sure content looks good before it goes out the door.
So, the functionality people really want is:
I’ve always thought that a CMS would be well-served by letting you “turn the page over and write on the back.” You know how Wikipedia has “talk” pages where people can have a meta-discussion about the actual content of the page (example)? Same thing. The average content editor just wants a space where they can call a time-out and discuss the content that’s being produced. Additionally, some of these discussions might need to be resolved before the content can be published.
- To collaboratively discuss content.
- To prevent bad content from being published.
Take a look at this wireframe.
We scoped this for a client on EPiServer, but sadly it never got approved. However, I still think the idea has merit. The major functional points are as follows:
(Note: there’s something else in the wireframe about requesting approvals, but it’s been 19 months and I can’t really remember what I was doing there.)
- Any editor can open a discussion about any piece of content. They can “turn over the page” and engage other editors and users in conversation about that content in the form of a simple discussion forum.
- Topics are tied to specific versions – so every thread is version-stamped, so you know what the current version of content was when the thread was opened.
- Topics can “block” publication. When a thread is opened, an editor can check a box that says “this version of content cannot be published until I remove this block.” An administrator could override, but the idea is that a single editor can block the content edit until it’s modified to their satisfaction or someone talks them off a ledge and they voluntarily unblock it.
I maintain this is really what 95% of people want when they say “workflow.” I have no doubt that “true” workflow scenarios still exist – there are legal, regulatory, and audit scenarios that require historical trails to be present. But these situations are further apart then we care to admit because we’re too busy showing off our shiny workflow solutions in a demo. Many prospects ask for these just because they’ve seen them in examples.
Give editors a competent solution for collaboration, and I’m quite sure that many requirements for workflow will simply evaporate.
By Deane Barker on May 20, 2014
Because I keep seeing the same problems happen over and over and over, I’m going to make this claim:
There is NO benefit to you in being talked into using a custom CMS which is hosted and controlled by a web development shop. DO NOT AGREE TO THIS. EVER.
We’re seeing this again and again: an earnest client is talked into letting a web development shop build their site on an in-house CMS, which the dev shop hosts. It’s an “end-to-end” solution, they’re told.
It’s all a myth.
I’m going to go one step further:
Any web development shop that tries to talk you into this is being reckless or naive at best. At worst, they’re being unethical.
At some point in the maturation of that dev shop, they faced a choice: do we (1) build our own CMS, or (2) learn to competently use one of the hundreds of available open-source or commercial options available. In this day and age, I’m completely mystified why people keep trying the first option.
Actually, I think this is dying out. I hope it is, anyway. I’m hoping that the organizations we see getting screwed over today are just unfortunate vestiges of some archaic past practices. Back in the day, this might have been a viable option. Back before the open-source world matured enough to provide so many great options.
But, in the darkest corners of my mind, some dev shop somewhere is staring down this choice today and still making the wrong one.
Think about this: if their CMS was really any good, other people would want to use it. If it was that good, they’d sell it, or productize it, or at least open-source it and make the code available for other people to see and use. If they don’t (and they probably don’t), ask yourself why. If they have managed to re-solve the problems of content management so damn well that you should sign onto their pipe dream, why aren’t other people using the software?
- “But all available CMS aren’t good enough,” they’ll say. Myth. When you look at one of the dozens of highly mature open-source options, do you honestly think you’re going to make something better with your two developers sitting in the corner while they also juggle client work? Really? You will manage to solve that problem better than, say, Drupal?
- “But all available CMS are too complicated,” they’ll say. Myth. Part of integrating means understanding the system well enough to make it understandable for others. You can take any system and make it palatable for an end user, you just need the desire to try. Suck it up and stop being lazy. If you can’t make Expression Engine simple for your client, then find another line of work.
- “But all available CMS take so long to learn,” they’ll say. Myth. So, you’re going to build a competitive system from scratch in less time that it’s going to take to learn someone else’s CMS? You can completely re-solve the CMS problem in less time than it would take you to understand TYPO3?
If you are a client facing someone trying to sell you this, here are your problems:
If a dev shop tries to talk you into this, do not walk away. Run. As fast as you possibly can. They do not have your best interests at heart. They are trying to put you in their system not for your benefit, but for theirs. The upside belongs completely to them – they get to be lazy, live in their own little insular world, pretend that they’re state-of-the-art, and lock you in.
- It will be worse than a real CMS. There is no way that dev shop can possibly compete with the state of the open-source market, to say nothing of the commercial market. If they tell you they’re better, then it just means they’re delusional or they don’t know enough about the current CMS technology to understand that they’re talking about.
- It will not develop quickly enough. You will see things on the Internet that you want to do. Be prepared for them to constantly tell you, “Yes, that’s coming in a new version” or “Yes, we’ve been thinking about adding that.” This will never get done. Advancement of their system will take a back seat to client work (as it should), and there is no developer ecosystem to fall back on. If they’re not developing on it, no one is.
- No one can help you but them. They’re the only ones who understand the system. When you start using any CMS, the community is a feature. No community means this dev shop is your only source of support.
- The CMS is tied to them. What if you actually like the system but hate the dev shop? Tough – it’s a package deal. You can’t pick it up and take it anywhere else. (And you know that developer you actually liked? He got sick of the BS and quit last week.)
- Your content is locked in. And this is the biggest problem: your data belongs to them. When you invariably decide the system sucks and want to move on, how do you get it out? What is their export/migration plan? How do you get all your data in a neutral format to put in something else?
Do not fall for it.
Do I sound pissed? I am. Too many times – several recently – I’ve seen good organizations get hurt by this. They finally realize that this custom platform is not meeting their needs, they make the hard decision to move on, and they suddenly face tens of thousands of dollars in migration expenses at best, and a obstructionist dev shop at worst.
So, are all hosted CMS options bad? Well, they’re not ideal, and I would never encourage one of my clients to use a SaaS CMS option (I’ve made this point before), but if you have to, look for two things:
Don’t do anything until you have good answers for the above two questions.
- What is the company’s main line of business – building this CMS, or doing web projects for clients? You want the former. Ideally you want a company like Squarespace that does nothing but develop their CMS as a product. You cannot compete with client work, so find a SaaS CMS company that doesn’t do any.
- Is there a decent export/migration plan? If (when) you want to leave, what are your options? How do you get your data out of the system in a format where it can be imported to something else?
This business practice just has to stop. I’m waiting for the first client in this situation to just man up and sue their shop for professional negligence. When it finally happens, I’ll be standing by, cheering them on.
By Deane Barker on May 8, 2014
Microsoft killed my Pappy: Scott Hanselman points out the truth: the Microsoft you’ve worked so hard to hate for so long is not the same company it used to be:
We’re putting source on GitHub, many groups are using Git with TFS internally for projects, we’ve open sourced (not just source-opened) huge parts of .NET and are still pushing. We’ve open sourced Azure hardware specs, opening SDKs, and we’re making systems more pluggable than ever. Frankly, we’re bending over backwards to NOT be dicks about stuff, at the very least in my corner of the company. Could we do better? ALWAYS. Are we pure evil? Nah.
But, of course, none of this matters because people are still going to hate Microsoft because they need someone to hate. Yes, Windows 8 has some stupidity to it. So does iTunes. So does Draconian control of iPod connectivity. So does a ton of stuff Apple does.
But, whatever. Keep hating if that’s what you need to be happy.
By Deane Barker on April 17, 2014
I talk at a fair amount of conferences. Over the years, I’ve taken notes on how to do it well (this pre-supposes that I do it well, which is very much up for debate). I figured I’d share these notes.
Now, understand that I give a very specific type of conference presentation, which is 30-50 minutes and always based around a presentation deck (a Power Point). This might not fit for everyone. Some of you might be doing a short speech unsupported by any visuals. If so, pick and choose from the sections below.
Also, I don’t offer this list as hard-and-fast rules, nor do I think it’s the only way to do it. This is simply what works for me. I concede that other people may have entirely different ways of doing it.
Here are my notes, edited slightly to make for a better blog post. If you’re staring down a conference presentation, I hope they help you. (And, in the true spirit of PowerPoint, these are in the form of bullet points, because that’s how I wrote them down originally.)
Questions to Ask the Organizers
The answers to these questions will help you, either explicitly or implicitly. The idea here is that it’s good to get as much background info as you can, because whether you’re aware of it or not, it will influence your talk as you put it together.
- How long do you have to speak?
Do they expect a Q & A period?
Where is the venue? What is its layout? A theater? A classroom? A conference room? (If you can visit the venue beforehand, or see pictures of it, do that. It really helps to be able to visualize the room when you’re rehearsing. Things that might work in one type of room will fail completely in another.)
Can you have a deck?
How many people are in attendance?
What events are before and after your talk? Another talk? Which one? Food? Going home?
What is the audience members’ relationship to the topic? How knowledgeable are they? Are they seasoned conference attendees, or is this rare for them?
Have they paid money to be there?
What is their expectation of learning? What do they hope to come away with?
How is your talk being advertised or promoted? What is the organizer promising – implicitly or explicitly – to attendees?
What is the tone of the talk?
Tutorial: insert tab X into slot Y
Informational: this is information about topic X you might not know
Conceptual: this is a new way of looking at or thinking about X
Narrative/case study: this is something we did in situation X
What is the scope of what you want them to learn? Are you trying to teach them something incremental, or something revolutionary? Do you want then to nod their heads and say “that’s some useful information I can use,” or are you shooting for “wow, that was mind-blowing!” The latter is riskier – it’s awesome when it works, a disaster when it doesn’t.
What is the point of your deck? Is it the focus of your talk — screencaps or something you will be talking about directly, or is it decoration and mood-setting?
What are the technical parameters? Will you be able to use your own laptop? How big is the screen? Will you have a monitor where you can see your deck as you’re giving it? Will you have a remote mouse (hint: bring your own).
Planning Your Talk
Start early. I know you don’t want to – it’s so much easier to avoid doing it because it can be scary and actually doing it brings you face-to-face with that fear. But the fear isn’t going to go away, it’s just going to get worse with time, so face up to it early.
Give yourself enough prep time. The rule of thumb is that you need one hour of prep for every minute of presentation time. So a 50-minute talk will take over a full-time week of work to put together. This, of course, varies greatly, and you may have a full-fleshed out talk in your head, ready-to-go. But, in general, understand that it’s going to take more time than you think it will.
Write down, in a couple bullet points, the things you want the audience members to come away with. In a perfect world, this is what they learned – this is the future state you want them to get to. These points will guide you while putting together the entire thing. You can “test” your talk against these points.
Write down the major talking points to support those learning points and put them in order – “to tell this story, I need to talk about X, then Y, then Z.” This divides your talk up into sections, which is important. Talks need to progress like a story – there needs to be a build-up, a center section, then a conclusion. A movie separates these with “plot points.” You don’t have plot points; you have section transitions.
Incrementally embellish each section. Treat it as a mini-talk by itself – “to tell this story (section), I need to talk about X, then Y, then Z.”
Don’t edit too much when putting this together. Go nuts. Pretend you have all the time in the world and make it as long as you want. Rehearsal is when you start cutting the thing down, and it’s better to start with too much information than too little.
Don’t be surprised if the content of your talk changes considerably through this process. Not only the specifics, but the entire nature and message. This sounds weird, but as you say things out loud and create slides to illustrate it, this has a way of catalyzing things in your own head. You don’t truly understand something until you have to explain it, and the process of explaining it will often make you think differently about it. (See “Rubber Duck Debugging.”) There have been several times when I was mid-way through rehearsals and suddenly realized, “I’ve been thinking about this all wrong…” or “My main point is not that important after all. Rather, this smaller point is really want I should be teaching them…” If this happens, don’t be scared – it’s a gift.
Preparing Your Deck
Transfer your outline to PowerPoint, or whatever. Most all of my talks are very presentation-based, which I realize isn’t true for everyone. But when I’m prepping a deck, I put my outline in Power Point, then start developing there.
For goodness sakes, understand how the software works. If you’re using PowerPoint, get a book and do some remedial PowerPoint training. This is stressful enough — don’t make it worse by not understanding what you’re doing.
A practical note: put the file in Dropbox immediately. You don’t want to lose it, and if someone goes wrong, you can retrieve it from Dropbox from any computer. There are several times when I’ve had to download a deck from Dropbox onto the presentation computer at the last minute. (Once, in Lisbon, I actually made a change 15 seconds before I went on, hoping that it replicated fast enough to beat me to the podium. It did.)
Do your title slide and your transitional slides right away, so you have a framework of the talk to work with. You have your sections set now, so you can concentrate on supporting them individually and telling the story around the transitions between sections. Also do the last slide — it should always be your contact information. So you should have the beginning, section headings, and final slide done first, which gives you a framework to embellish.
Don’t worry about design too much. If your slides need a theme, and if you know how to work your presentation software, you can apply it towards the end. (The current trend is away from design – the plainer the better these days, it seems.)
Do not pay attention to any guidelines about how long to talk over a slide. I’ve spent five minutes talking about a slide. I’ve also spent five seconds. I’ll often have a sequence of five slides that I rip through in 15 seconds. It’s not important – your talk matters more than the slides. They are there to support what you’re saying.
Rehearsing Your Talk
Rehearse out loud, by yourself, to an empty room. Yes, you’ll feel stupid. Tough — better to feel stupid by yourself than in front of a group.
Rehearse the entire talk at least 10 times. Yes, that is a lot.
Get a remote clicker. Walk around. Gesture. If your dog doesn’t look at you funny at least once every rehearsal, you’re not moving enough.
Rehearsals have two different flavors:
Exploratory: this is a loose run through, when you stop and adjust slides, change things, etc. You can stop in the middle and edit.
For Time: keep going through, no matter what. This is how you’re going to determine if you’re within the time boundaries.
Don’t always rehearse from the beginning. The goal is to be able to pick up at at any point in the talk and carry through to the finish. So, in addition to doing the entire thing, start ¼ of the way through, ½ of the way through, right at the end, pick a random slide and start from there, etc. If you start from the beginning all the time, then the beginning gets a lot of focus, and the latter part of the talk doesn’t get your full rehearsal attention.
Try to get Presenter View (a PowerPoint thing; Keynote probably has something similar) — you should be able to see the upcoming slide on a separate monitor at all times, with your notes if possible. If not, print the presentation notes out before hand. (Though, honestly, if you have to refer to your notes at all, you probably didn’t rehearse enough.)
If a slide doesn’t feel right, it probably isn’t. If you’re tripping over a slide, and it just doesn’t sound right, get rid of it — either drop it, or combine it with something else. So long as you have enough time before you have to talk, don’t be afraid to do major surgery. Slides that sound wrong, probably are wrong.
If you’re using notes, don’t write them as if you’re going to read them verbatim. Write bullet points that will just jar your memory of the points you need to cover.
Concentrate on your last section. This is the payoff, and too many times, people rehearse solely from the beginning so by the last section, they’re just trying to get done. Rehearse the last section by itself multiple times.
Giving The Actual Talk
Show up early, and make sure AV is fine. Get your presentation up on the screen before anyone shows up, and run through it quickly to make sure it looks right. You do not want surprises (“Where is my custom font?!?!”) right before you talk.
Have a remote clicker. Always. Podiums suck.
The goal is to have the talk feel conversational, not formal. Meet as many people as you can before the talk. As the room fills up, go introduce yourself and talk to people. Your goal is to make them feel that they’re in this talk with you, not that you’re giving it and they’re receiving it (even though that’s exactly what’s happening).
If you can, start with some comment about the event or something that just occurred: “I was just talking to Mark in the hall…” This sets people at ease and takes you immediately off-script, so it sets expectations on the conversational tone of what follows.
Don’t read from the presentation. This sucks for a lot of reasons, but mainly because you’re setting yourself up to be super-rehearsed, and if you have to ad lib, it becomes totally obvious that you’re off-script. You should sound off-script all the time.
Be explicit about the section transitions. “Okay, so I’ve just explained what X was, now I’m going to talk about why X is important.” The audience wants this – they want to know that they’re moving steadily through the talk. They want to mentally organize the content: “What did I learn in that last section? I need to store that away, because this is a new section with a new thing to learn.”
Try not to be nervous. I know this sounds like a ridiculous platitude, but here’s why it’s important: if you’re nervous, the audience will be nervous too. They’ll be scared for you, and they’ll subconsciously resent you for it. If you’re relaxed and having a good time, the audience will be too. Remember this: they want to like you. They do not want to see you fail. If you make them feel awkward, it’s harder for them to like you.
If you think of an anecdote, tell it. Remember, you’re not on a strict script here. Feel free to weave in and out of your rehearsed outline. I don’t think I’ve gotten through a single talk where I didn’t extemporaneously say something that I never rehearsed.
Gesture at the screen. Point at stuff, if appropriate. Look at the screen yourself. You want the audience to feel like this is something you’re looking at together, not that it’s just background information.
Last slide is contact information. Invite people to contact you with questions, or if they want to talk about anything you presented. It has practical value, and it’s a nice, clear way to signal that the talk is done. The audience wants to know when to clap, and they’ll feel comfortable with an explicit cue.
If you want some more good tips, take a look at this: 11 Top Tips for a Successful Technical Presentation. In particular, read the comments there – lots of great stuff submitted in the comments. It’s also worth noting that Scott Hanselman is the presenting style that I really try to emulate: he’s so wonderfully relaxed when he talks that you feel like you’re in it with him, rather than being lectured to.
If I could replicate one talk (in vibe and style, not so much content), it would be this one: It’s not what you read, it’s what you ignore. That’s Scott at WebStock 2012 in New Zealand. It’s fantastic.
It helps that Scott has spoken at my company, sitting at my breakroom table. It’s easy to like someone when they do that for you.