Category Archives: User Interface

Designing beyond the surface layer

Designing a user experience is usually considered synonymous with the work of designing the part of a system users will directly interact with.  While that is all good and well, a general problem I see in the UX practice is that this then becomes the place where the UX work not only begins, but also where it ends.  In other words, the underlying functionality, the components that actually allow for the interaction being designed to function is either completely ignored or only given cursory consideration from a UX perspective.

This lack of attention to the impact of the non-visible aspects of a system on the user experience is, in my opinion, a major reason for a lot of bad user experiences.  If you think about it, if your page is slow to load, if you try typing into a text field but nothing happens, if some seemingly simple action in the UI in fact initiates connections to a bunch of data sources and causes whole interface to become sluggish, who cares how perfect your UI design is?

I think a lot of UX designers shrug their shoulders at issues like this.  Hey, that’s the developer’s problem not mine, right?  Yup, definitely the developer’s problem, just like the proverbial leak on his side of the boat is his problem and not yours.

The issue here is not one of who is responsible, rather one of an awareness that it may critically impact the user experience, and therefore the User Experience design process should be one that allows for surfacing the issue and addressing it.  Current conventional methods of UX design, i.e. focusing solely on the user interface first, then waiting to deal with pesky issues such as load time later is only likely to ensure that those issues get relegated to the revolving “Phase 2″ version of the application.  A better way to address this is to rethink the relationship between UX design and development, and a great example of that is to evolve the GUI in tandem with the software build.

An Agile UX Method: Functionality First, GUI Second

The idea of designing the user interface in tandem with the build is a good example of applying Agile thinking to UX.  Here, instead of first creating some fully formed interface concept before starting to actually implement it, we take a step back and look at what underlying functionality needs to be developed.  In cases where it makes sense, such as a piece of  functionality that may be simple at the user interface level  but where there may be some heavy lifting on the back end, rather than spend a lot of time at the outset trying to come up with the perfectly user-friendly UI, we instead abstract out what inputs the user will provide and what outputs the system must return and then create a minimal user interface, of which the most standard is the command line interface.

Example of a minimal user interface, showing only user inputs and outputs

Example of a minimal user interface, showing only inputs and outputs

Here is an example of an auto parts search, in which we know that actually connecting to the various parts warehouses and then executing the search is going to be highly complex.  Therefore, before spending a bunch of time designing a GUI, which will need to make assumptions, for example, about the amount of time that will be required to complete a search, we instead start by building a first iteration of the search functionality and use a skeleton user interface.  With the knowledge of the actual average time of completing a search, as well as issues related to connecting to the warehouses, we are in a much better position to build a graphical user interface around this, in which we can clearly set user expectations, as well as determine much more effectively what forms of dynamic features in the UI we can support, such as how much flexibility we can allow for in terms of user inputs. (I.e. maybe we discover that Name needs to be a separate field from ID or whatever.)

This can be an incredibly powerful way of working, since it actively and organically involves developers into the design process, allowing you to collaborate much more closely in evolving the user interface.

Three Amazon Design Ideas

Inspired, in part, by Jared Spool’s recent article regarding  the impact of design changes at Amazon.com and the related talk he gave at the IA Summit, I thought I’d post a few Amazon redesign ideas that have been percolating in my head of late. Of course, these ideas are presented without access to Amazon’s vast research data or internal business knowledge. Who knows, with that knowledge in hand, I may have suggested very different ideas.

A Pixel Saved is a Penny Million Dollars Earned

There are few sites on the web where even an atomic-level change in the user interface can potentially have greater impact on overall product sales than at Amazon.com. For this reason, every character, every pixel needs to be scrutinized and justified in terms of supporting the overall goals of the business. In line with that, these are some ideas for eliminating possibly detrimental pixels in the all-important Add-to-cart area.

Here is a Before/After of the Shopping Cart area on an Amazon detail page:

Current version

Add to Shopping Cart - before

My version

Add to Shopping Cart - after

There are three key changes I made here, which allowed for eliminating quite a few pixels:

  • Removed the quantity option: The ability to select a quantity prior to adding an item to one’s cart seems to not only be an edge case, but also something which, if the option were removed, would be unlikely to cause users to not add the item to their cart. After all, once having added it, they can then update the quantity option to their heart’s content. Removing it, in other words, would mean less page noise at virtually no cost to usability.
  • Removed an unnecessary technology reference: Below the Add to Shopping Cart button, anonymous users see a link and some copy encouraging them to sign in to be able to make use of 1-Click Ordering.  The problem here is two-fold. First, by linking on the word  “Sign in” this is what is implied as the main goal of the message and also what will draw the eye.  Signing in is of course not the main message here.  Second, even including the detail that accessing the 1-Click-Ordering feature will require signing in really only becomes a distraction, since it really isn’t relevant until a customer actually decides that they want to activate the feature.  The primary message is to encourage users to turn on 1-Click-Ordering, and that seems to therefore be most effectively communicated by replacing the whole ball of wax with a single call to action.
  • Combined multiple modules into one and added some hierarchy: Because Amazon provides so many great purchasing options, this tends to lead to a whole gaggle of buttons collecting in this area, some of which are inside a module and some of which are not, making for a slightly harried viewing experience.  Here, I cleaned up the whole thing by placing everything in one module, and then used the dotted horizontal rule as a much more low-key division between groupings.  I also added a bit more hierarchy, such as making the text for the somewhat secondary “Share with Friends” feature smaller.

Much of what is manifested in these changes is the critical value of succinct writing skills. Good user interface design is very much like good writing, i.e. the ability to say what you have to say with the fewest possible words and then saying no more. (As opposed to this completely extraneous sentence.)

Make marketing action-driven

Here is an example of a marketing blurb for the new Kindle 2.

Kindle Promo, Current Version

A key issue with this message is that it requires the user to read through a bunch of copy to understand what really is a simple message (see below.)  Already there, you’re going to lose quite a few users, who, after encountering that amount of copy (a lot in this particular context), will be off scanning some other part of the page.

Then, and this is even worse, for those users who take the time to read the message and in fact would now like to take the action that the message is promoting, it is in fact not at all clear how they should do that.  Should I click on the link with the name of book? But that’s the page I’m already on.  Hmmm…

Finally, the message suffers from providing information at a level of detail beyond what the user really needs to know. For all intents and purposes, “in under a minute” is the same as now, which of course is a far more compact and powerful message.  That’s what customers care about. That’s the essential selling point.

Therefore, my recommendation is to replace this text-heavy marketing message with one that strips it down to its absolute essence and doubles as the action that the message is selling.

Kindle Promo - Redesign

Here, we are not only communicating that the Kindle allows for reading a book immediately (which is a major selling point that I actually was not aware of until I started reading the Kindle marketing materials more closely), but we are also presenting a clear path for initiating that process.

Less page, more opportunity

Currently, the Amazon page width is set to 100% max-width, meaning that the maximum width of the page will be whatever the width is of the browser window.  Now, for users with smaller monitors, this issue will go unnoticed, but for the growing number of us with wide screen monitors, an Amazon page might look something like this:
Amazon wide page view

With a page this wide, the overall page design quickly starts to break down: the long lines of text become more difficult to read, the search input form becomes so ridiculously long it ceases to look like a text field, and the Add to Cart area loses its association with the content it is referencing and looks more like a third column.

Allowing the page to continue expanding to this width is, in my opinion, not only a degradation of the overall user experience, but also an opportunity lost. In other words, constraining the page width to one that is optimal to the content it contains creates a whole new area available for things like marketing. This is something that others, like the good folks at Pandora, already have figured out.  So, my recommendation here would be to constrain the page width to one optimal for reading, which, for the current design seems to be a 1024 pixel display, and then use the new-found real estate for marketing purposes.  Something like this:

wide-screen-view-constrained

Better legibility, usablity, and new-found marketing opportunities all-in-one.

To be clear, I think Amazon is one of the best designed e-commerce sites on the web, and I’m sure that an incredible amount of thought and effort went into the designs I am critiquing.  But maybe it is that very fact, the knowledge that these pages were designed by some of the most skilled people in the industry, which makes it all the more enticing to find ways to improve upon their ideas.

You’re idling, lazy user!

Here is an interesting little message I was greeted by while doing my usual multi-tab sweep of news/todo/email/twitter/etc this morning.

you-idled

What I think is so interesting about this seemingly innocuous little message is how much it tells you about those who designed it (or not, as it were.)  Here are a couple nuggets one might glean:

The 15 minute timeout was likely set with no consideration for UX or the business context

This message appeared because my session at this site had been automatically ended, since I had not clicked on anything during the time allowed for inactivity during a session. For those not familiar with this, there are two reasons why one would want to time out a session:

  • Conserving server resources: every additional user session takes up some resources on the server, so you’d want to conserve by ending sessions where there is no activity.  However, this has become far less of an issue after storage has become cheaper and processors faster.  And even if this were a factor here, timing out after 15 minutes would almost certainly not be necessary.  More likely, it could be set at 1 hour or the like.
  • Security: This is the far more common reason to limit a user session.  If, say, this screen shot were from a banking site or the like, well, I wouldn’t be posting this, because a 15 minute timeout would make sense.  After all, you don’t want to risk someone being able to access your checking account while you had to leave your computer for a couple minutes (maybe having forgotten that the account page was open in a different tab.) But this is no banking site.   There is very little, if any, damage that someone could cause if gaining temporary access to my account here.

In other words, for this business context, a 15 minute timeout makes no sense.  I’m guessing this was set by a developer, possibly without even any discussion with the UX designer, maybe because that person wasn’t even aware of this, on one hand very technical issue, but on the other hand one that can significantly impact user experience. And it is incredibly unlikely that this limitation is due to a need to conserve resources.  A 1 hour timeout would likely  make more sense.

The accusatory tone (“you idled”) reflects inexperience writing for the web

When writing for the web, particularly when writing interface labels and dialog copy, surgical level word choice is critical.  What is so unfortunate is that a lot of interface copy seems to default to accusatory and unnecessarily dramatic (“Warning!”) language.  An experienced author would have been sure to both strike a more empathetical tone, as well as explain why the session had to be ended.  Maybe something like:

You haven’t clicked on anything in the last 30 minutes. To protect the privacy of your personal content, we’ve automatically signed you out.  We apologize for the inconvenience.

Please sign in again

It’s interesting how much a tiny little detail can tell you about the person who designed it.

The Curious Case of the Gmail Buttons

Earlier this week, when checking my email, I noticed that our friends over at Google had made a couple changes to the buttons above the inbox.

New Gmail Buttons

For reference, this is what the buttons looked like before the change (and without my custom theme):

Old Gmail Buttons

The first change, adding the Move To and Labels controls, are welcome changes.  The other change, redesigning and removing the spacing between the buttons, not so much.  The reason for placing the buttons flush against one another is likely the result of, after having added more buttons, deciding that this increased quantity of buttons warrants the need for grouping them.  While that’s all good and well, the decision to actually have the buttons completely flush against one another was a bad decision indeed.  Unwittingly, the geniuses at Google have not so much created a group of buttons but really instead created what visually is–particularly for the rapidly scanning and hunting Steve Krug archetypal web user–one big honking button.  This means that every time I want to take the very very common action of deleting something, I can’t just target the delete button, I have to scan the Gigantor-button to find the part within it that contains the delete section. And after having used this redesigned version for a few days now, I am still finding myself scanning for the delete portion.

This type of UI flubber, a bad design choice that on one hand really only leads to a fraction of a second’s delay, is what I call a micro-annoyance.  Now, let’s say this micro-annoyance appeared on some registration form.  That wouldn’t really matter too much since I would only have to deal with it once.  But when it appears on something that I use every day, all day, all the time, that changes everything.  Suddenly it is significant.

What’s truly annoying, though, is how easy it would be to fix this issue.  Just add a couple pixels of spacing between each of the buttons.  Something like this:

Gmail buttons with spacing added between buttons

You basically get the best of both worlds – you keep your button grouping, while also removing the micro annoyance of making me scan for the Delete button every time.

The Problem with Todo lists (the digital ones)

Let’s imagine for a moment that you’re some seniorish UX design person and I’m your client and I ask you to design for me a truly durable and useful todo list.

I can imagine a variety of reactions to this request. One might be “Why in the world do you need me to design a todo list when there are like a gazillion todo lists already out there?” Another might be a shrugging of the shoulders, thinking I’m giving you a chance to make some easy money to design yet another todo list. But if you’ve really been around the design block a few times, you’d know better than to assume that a seemingly simple request coming from a client really is that simple. (In my experience, that is rarely, if ever, the case.)

So, you dutifully inquire further as to what my specific needs are relating to a todo list, i.e. when and where I’d be using it, what type of todo items I’d be entering, how I’m currently managing my todo items and so forth. Here is one of my responses:

I’ve used all kinds of todo list software, from the new Gmail Tasks, to 37 Signal’s Tada Lists, to just typing stuff into notepad or Google docs. Many of these pieces of software are very simple and elegant and user-friendly, but, even so, what always happens is that I use it for a while, eagerly typing in everything I need to do, but then I stop using it after maybe a week or two, sometimes less, usually because it’s just too much of a hassle to have to type stuff into these lists. So I end up with todo items scattered all over the place.

Whoa, wait a second here. Maybe this todo list thing isn’t that simple after all. Taking an Alan Cooperish what-if-software-was-magical approach, you ask me what my ideal dream todo list might look like, setting aside any technical or logistical constraints.

For me, the issue is primarily with the hassle of having to enter items, of having to get in front of a keyboard and fire up some application when I think of something important, especially when I simply can’t or don’t have the time, maybe I’m riding my bike, in the shower, in the midst of a conversation with someone, don’t have internet access, whatever. So I end up not entering it, which of course negates the whole point of a todo list. So, in terms of my dream todo list, and this will sound a bit weird, I think it would have to be one which it basically reads my mind or something and when I think of something I need to do, it would add it to my todo list in the cloud, as in some kind of universally accessible list of stuff to do.

The other big issue is having to deal with categorizing and prioritizing todo items. While I’d like for them to be organized nicely, I don’t want to deal with having to come up with categories not to speak of having to do the categorizing. So it would need to be able to somehow figure out how to group my todo items in a sensible way, such as work-related and personal todo items. And as far as priorities go, I’d obviously want higher priority items to be more prominent, but the problem is that the priority of a todo list item changes for me depending on context and other factors. For example, if I am at the office, even though I absolutely have to remember to pick up a bottle of wine on my way to the dinner party this evening, I don’t want that todo item cluttering my list of office todo items. But if I maybe head out for lunch, then I’d want to see it, since my priorities and my context then has changed. Yeah, that would pretty much be the ideal dream todo list.

Ok, so on one hand this is a dream todo list app, but let’s look at what this imaginary software tells us about current todo lists and design in general.

The more contexts your design needs to support, the more complex it will be to design
A todo list is reflective of how the software we design is increasingly intertwined with people’s lives. As such, a todo list that a real person really can use in their day-to-day activity needs to work in all kinds of contexts. Compare this to a todo list that strictly is for work-related items: in that case, I can maybe assume that the user will always be in front of computer and as such as traditional todo list might work. But even that falls apart, since I may also be on the road, in a meeting with a client at a coffee shop, in front of a whiteboard.

Categorization is a Catch-22 Conundrum
On the one hand, users like for stuff to be organized in a way that makes sense to them. At the same time, they are unlikely to want to have to deal with coming up with categories or with the hassle of categorizing. While creating some generic todo list categories (e.g. work, personal, buy, etc.) is probably doable, user would still have to actually place stuff in those categories, which adds yet another obstacle, another micro-activity that will make the act of entering a todo list item less palatable.

Priorities are contextual
There are lots of things we think of as important, but only some of things are important in a given context. This means that we can either have multiple todo lists for different contexts, which means a lot of busy work, which means we are likely to stop using the todo list. Alternately, we could use category-specific indicators, such as high priority work, or high priority personal, but again, we are then back to the problem of too much hassle to deal with when enter a todo list item.

Sometimes there really is no great solution within the digital domain
With today’s mainstream technology, it is not possible to design a durable and truly useful todo list. Please prove me wrong on this.

Instead, this is the todo list solution that I always find myself returning to:

Using an old envelope as a todo list

Yup, the back of an old envelope. Why is this tattered looking thing better than any of the todo list software out there?

It’s highly portable
For the very reason that it’s just an old used envelope, I can crumple it up and stick it in my pocket. If I spill coffee on it or it gets a little torn or whatever, who cares?

It’s always immediately accessible
No booting up an iphone app or, yikes, a laptop, just to enter a lousy todo item. No battery life or connectivity issues to think about.

It constrains me to a reasonable amount of todo items
One of the biggest problems with most current todo lists is that they, in a knee-jerk nod to the idea that infinite scalability is a good thing, don’t impose a limit on how many todo items I have on my plate at any one time. But a list of hundreds of todo items, I think, is pretty useless, as I am only going to be able to do a few of the items within the near term. So, the size of the envelope constrains me to a reasonable amount that usually matches what I can complete in a day.

It allows for ad-hoc prioritization and categorization
Since I can write anywhere on the envelope, I can add little stars or underlines or write in all caps or whatever to show that something is important.

But, of course, using the back of an envelope for a todo list has all kinds of drawbacks, which leads to another UX lesson:

Design is not about finding the ideal solution; it’s about finding the ideal compromise
Obviously, using the back of an envelope or a piece of paper has all kinds of drawbacks, from that you have to manually transfer todo items that weren’t completed to a new piece of paper, or that you could easily misplace it, or that all your scribblings could quickly turn into a big jumbled mess. But weighing all those drawbacks against the strengths of the solution, I still kep find myself returning to this method after temporarily trying some new software-based todo list.

Is it just me or are others having similar experiences, finding digital todo lists just not workable in the long term?

Three ideas for improving iPhone data roaming usability

As I am currently spending the holidays with relatives in Stockholm the issue of data roaming on my iPhone has suddenly shifted to front and center. After updating the software to v 2.2, I had somehow hoped that the various usability annoyances of this feature, which goes from being virtually inconsequential for most users to being a core feature for international travelers, would have been addressed. Not so, unfortunately. In fact, it seems that the only party that has taken some action in this area is the carrier AT&T, by sending a helpful text message when the iPhone connects to a carrier other than theirs. Apple, on the other hand, while in most other ways having created a masterpiece of good user experience in the form of the iphone, seem to have let this particular ux aspect slide a bit.

First, a bit of background. When the very earliest buyers of the iPhone decided to take them abroad, they made two key discoveries. First, the iPhone and all of it’s features work almost seamlessly anywhere in the world where you can get cell service. Second, the fee for this convenience is astronomical. Early adopters of the iPhone would return home to be greeted by bills from AT&T sometimes in the thousands of dollars. One reason for the high cost is that the iPhone displays real web pages as opposed to the watered down web pages on cell phones of old, meaning that the amount of data being pulled down increases significantly. Now, while using your phone in the US this is not an issue since the data allowance for AT&T users of the iPhone is unlimited. Not so when traveling abroad. And the feature which determines whether or not you will have access to those conveniences and also incur the astronomical expenses when abroad is the data roaming feature. Let’s therefore look at some ways in which the feature could be improved.

1. Set the feature to be off by default when accessing a non-native carrier

Just like AT&T responds with a text message when the iPhone connects to a non-AT&T carrier, so too should the iPhone make an equivalent adjustment. In line with a basic principle of UX to do no harm (i.e. to incur additional expenses without first notifying the user), the default roaming feature should be deactivated. Better yet, a notification could appear the first time the iPhone connects to a non-native carrier, allowing the user to decide what to do.

1. Make changing the data roaming settings easier when abroad

Currently, when having turned off data roaming, and trying to connect to a web page or whatever, a mildly helpful message appears, explaining how to gain access to the web page, describing the multiple steps required to access this very buried feature. Why not instead just provide access to the feature, allowing me to turn it on? Obviously, I am interested in getting online, so why do I have to exit the browser, and dig down into the iPhone settings and then back again to the browser? Better yet, why not have the iPhone go into International mode and make features like this accessible with a single click? Additionally, there should be an option to only leave data roaming on for a limited time period. Perhaps this seems like feature bloat, which is one of the very things the designers of the iPhone have done so well in preventing. I would say that it is not, since the additional features are highly contextual.

3. Replace ‘data roaming’ with something more understandable to non-geeks

Unless you’re a networking dorkball, you are unlikely to understand what “data roaming” means. This is a great example of where technological jargon has been allowed to surface up into the user interface label. Why not something like “international mode?” Of course, technically speaking, it is possible to need this feature without having traveled abroad, such as if you are in a domestic location where only non-AT&T carriers are available (I actually don’t know what the fees would be in that situation.)

Part of me knows that this feature upgrade probably isn’t at or even near the top of Apple’s list of iPhone upgrades, but nonetheless, I’d be curious to know if others have had similar frustrations.

Twitter’s Reply Weirdness

One thing about Twitter that I’ve never really understood is the way that the reply to feature works, i.e. the ability to precede your tweet with @[username] of the person whose tweet you’re replying to.

Replying to another tweet in Twitter

Let’s say the person I’m replying to happens to be a user that I’m following but they’re not following me. In that situation, shouldn’t Twitter let me know that the user I think I am going to reply to isn’t going to see my reply? In other words, when using @reply, won’t users think that their reply will actually be seen by the intended recipient? The reality, of course, is that the only person who sees my reply is me and those that are following me. Maybe there is something about Twitter that I just don’t get, but it would seem as if, when someone clicks on the reply-to link, that Twitter should check to see if that person is following you, and if they are not, display a message to the effect of that this person won’t see your reply.

Is it just me, or is not having a message like this a ui screwup?

Firefox 3 – Back Button UI Annoyance

I’m currently using Firefox 3 RC2 FireFox 3 and absolutely loving it – I love the new tags feature, the overall faster browsing experience, everything…

Well, almost. One thing that I find quite strange is the location of the control for jumping back several pages:

Firefox Back Button - actual

I remember the first time I needed to go back several pages and saw this and sort of looked at it like “hmm, seems like you can jump ahead several pages, but how do I jump back several pages?” But after clicking on the little control, it turns out that to go back several pages at once, you click on the control next to the forward link:

Firefox back button clicking on multi page control

Unintuitive indeed. Would it not make sense to have this control be next to the back button, maybe something like this?

My version of the Firefox back button

Here, the location of the control maps to our mental model of where we want to go, as in backwards.

Favicon Usability (or, please let me use them as buttons)

Over the weekend, I think, Google updated their favicon (or shortcut icon) …

New Google Favicon with lower-case g

First off, I was pretty confused when I saw this, since seeing that g out of context doesn’t remind me at all of the Google brand. The old favicon was much better:

Old Google Favicon

While that lowercase g could be pretty much anything, it’s hard to confuse this with anything other than Google. But worse, and this was the case with their previous favicons as well, they have the same favicon for several different services, such as search, maps, and news.  So why is this a big deal (or a small-big deal)?  Well, I use favicons as buttons in my bookmarks toolbar…

Example of how I use favicons as buttons

This is a great way to conserve space.  The only requirement is that the people who are designing the website are thinking about how favicons might be used.  (Ok, in addition to the requirement of having a favicon in the first place.) Maybe what I’m doing is a bit unusual – basically turning favicons into buttons by removing the text description, but it seems to make sense, no?  So, if you happen to be someone who designs favicons or has any say about it, if you’re working on a suite of services, don’t use the same favicon for all of them.  Even if users aren’t being nerdy like me, it still makes it easier to target the right app if it has distinct visual mark or brand.

JotSpot reborn as Google’s version of BaseCamp

JotSpot used to be my favorite Wiki tool and I was so sad to see it vanish after being acquired by Google. Today, at long last, JotSpot is back in the form of Google Sites. Weirdly, the only way you can sign up to use it (for now), is if you have a Google Apps account – which I think is something primarily used by small businesses. Not sure why Google would assume that individuals would not be just as interested in this tool – for the same reason that BaseCamp is used both by teams and individuals. Well, no matter, I happen to have a Google Apps account and started playing around with the app – and I have to say, I wasn’t very impressed. Sure, it’s still in ‘Beta’ – but Google has sort of shot themselves in the foot with their liberal use of that term (with Gmail still in Beta, Google has basically rendered the term meaningless) – so because it’s meaningless, people ignore that supposed message that things may not be quite working as expected, and expect everything to work just right. The whole experience still feels a bit clunky, at least by Google standards – for example, I created a new page, assuming it would then show up in my list of pages in the sidebar – but for some mysterious reason, I have to go into the settings for that page and choose to have it display in my page list – makes no sense. Considering that this app is integrated with the apps suite, it’s also not clear to me what the relationship is between the various dashboards you can create as part of this app and the dashboard that is part of the Google Apps suite – to be clear, this is not the same as the iGoogle dashboard. In fact, it seems like Google in general is having a bit of an IA problem – lots of apps all sort of interconnected but no overall semblance of order.

Anyway, bottom line is that Google Sites will probably be a worthwhile Wiki, Team Tool, whatever, eventually, but for now, it’s still a bit rough around the edges.