I’ve had a post written for the workshop for about two weeks now. I haven’t posted it yet as I wanted to add images. It would take me 10 minutes to take and upload the images, but I’ve been putting it off.
This one little thing of adding a few images has added enough friction to publishing the post that I’ve put it off for weeks. I could (and probably will) just post it without images, as done is better than perfect and not done. But that tiny bit of extra friction has stopped me in my tracks.
Next time you find yourself stuck, try and see what is creating the friction and if its not critical just remove it. Remove all the friction and see how fast you can get things done.
A large part of developing great products takes place by curating your taste for what makes a good product while you build it. A shortcut to build this taste it to constantly be looking at the software we use with a critical eye and asking ourselves why did they design this the way they did, and more often than not, asking what the hell were they thinking.
The easiest mistake is to avoid is to including too much information or irrelevent information on a screen. Often we include information almost sub-consciously. We saw a competitor do it, so we automatically assume we need to do it too.
For example let’s say you have a conference cataloging website and you want users to view and attend more conferences. When they view the details of a conference, how do you decide what to display, if anything, after actual conference details?
Does it make sense to show a “Recently Viewed” or a “Related Conferences” list?
The answer is not one or the other. The answer is to look at this from the perspective of what isyourgoal for users onthatpage inthatwork flow?
If the goal is to get users to browse more conferences so you can hopefully sell them more conference tickets, then it makes sense to show them other conferences.
If the goal is to find more information about one specific conference then sending them off to other conference detail doesn’t help them at all. Would a map of the conference, a list of other people attending, or previous year’s talk videos be more valuable?
Then think through any technical aspects. Can you show good enough related conferences that would actually be of use to people? Just because I’m looking at a python conference in New York…does that mean I’m interested in one in Texas?
Documenting your goals for each screen helps focus you on the core purpose of the screen and helps you from adding unnecessary information.
I go through spurts of writing new posts for this workshop.
I’ll have a single night of inspiration and write four or five posts, and then do nothing for the rest of the week. In the past when I’ve had these inspirational periods I’ve scheduled the posts to be published over a period of time rather than all at once.
It seemed a good idea not to throw too much content out all at once. It would give the audience a chance to read it all before new posts were published. The website would also feel more active with new content every few days, rather than a bunch of posts one day and none for weeks.
But with this workshop I think that is the wrong mindset.
We don’t care about numbers, so why should we be doing stuff to specifically try and get readers to come back more often. We are writing for ourselves, so we should also be publishing for ourselves.
So from now on I’m going to try and break my habit of wanting to spread out posts and just publish them when they are done.
A lot of people start projects and then give up on them. We are no different. So we didn’t want to announce or link to this workshop until we had built up a little momentum and posted 20 or so items. That way we might start to form a habit of posting stuff here, and not just give up after a week or two.
Doing it for ourselves and not others I think has really helped. It’s taken away the pressure that comes from putting yourself out there, and has made it more enjoyable to just drop into a text editor and write a quick post here and there.
When we’ve been designing Kwoosh, we’ve aimed for an interface that’s both minimal and easy to use. Striking that balance can be tricky. Minimal interfaces often look cleaner in a screenshot, but are a travisty for users that are unfamiliar with how it all works (Even after writing 10+ posts on Medium, I still had to lookup keyboard shortcuts for all but the most basic operations).
A common mistake designers make is removing text in favor of color. A splash of red or green looks so much better in a screenshot, how does it work?
Can a first time user glance at interface and know what green means? What if your user is color-blind, can they evenseegreen?
This said, it may sound like we’ve made a mistake with Kwoosh. After all, the main way customers categorize tasks in a single list in Kwoosh is by color: none, red, orange, yellow, green, blue, or purple.
The difference is that we don’t assign any specific meaning to any color. Color means whatever you want it to mean. You’re not stuck withourvocabulary when talking aboutyourwork.
With the change over to Vue, it has allowed us to go back through our code base and wonder what the hell we were thinking over the past 18 months.
There is a lot of left over legacy code from change after change as we were building the system and trying different things out. We now know exactly what we want and how they should work, so its a great time to go in, clean things up and stick to a single coding standard.
It’s a great feeling to remove a bunch of code and to simply things. Hopefully by the end of the switch things will be much simpler and easier to maintain going forward.
Had a slow start to the week, but we are finally starting to get back on track.
We started the week by changing out the built in django user model with our own. This allows us to customize it and move around a bunch of user profile stuff that was previously in a separate profile object.
The change over process was easy…a few copy and pastes and a config setting or two and it was done. The real annoying stuff came after trying to track down old references to the user profile that no longer existed. You can get 99% of the way with a global search and replace, but those last few references were hard to find and took up a day or two of development time.
It’s all sorted now though. We have changed it out and everything is working again.
Like any good programmer, I’m lazy. I try to let the machine do as much work for me as possible.
I wonder if this is a good thing. It feels like as software has gotten more features, developers are depending more and more are large frameworks to do the heavy lifting.
We need a fancy component in our interface, so we use a library that lets us implement it in hours, rather than days. Win, win, right? Maybe not.
This library pulls in a bunch of stuff we’re not interested in. And for some reason causes our app to take 30% of the CPU when the app is idling doing nothing. Do we stop and debug and maybe even patch this framework or do we just move on because “hey, the app is still responsive”.
The end result is that developers may not fully understand how the software they’re writing actually works.
Use frameworks and be lazy, just make sure that you understand them or be prepared to rip them out.
In the startup world there is a badge of honour around working 80 hour weeks and only taking two days off a year. It’s total crap, but I think a lot of people think its true.
You just can’t continously work for that many hours over that period of time. Yes there will be some occasions when you have to work 12 hour dys to hit a deadline, but more than a few of these a month and you just get burnt out. And once your burnt out it can take months to recover.
So take a break.
I’ve been working hard on moving Kwoosh over to the new front end recently. I’ve spent a good three weeks solid on it and can feel my productivity on it slipping. I feel that I need to take a break from it.
So here I am…taking a break…I suggest you do the same too.
A lot of different things go into a login process.
At first it sounds like a very simple idea. It’s a form with two fields, a username/email and a password. The user fills in the form and is logged in.
Once you then start to dive in deeper a lot of questions and design decisions start to crop up.
Do you use usernames or emails? You only need a unique value to identify the account. So is best to allow a username or just stick to an email address?
If a user enters the wrong username/email how can you show them? Do they have to wait until they submit the form to get an error message? Do they get a specific error message that the username is wrong? How do you let them know that the username is correct but the password was wrong? How can you show them that they are a single character out on their email address? That they entered “firstname.lastname@example.org” instead of “email@example.com”.
What if the user then forgets their password? If you use usernames, what if they forget that? What if they forget their email address? Do you send a password reset link in an email? Do you include a link to view their online email if they have an @gmail.com or @yahoo.com address? Do they have to answer a secret question? Do they get logged straight in after they change their password? Can the password be the same as their old one?
All of these questions have different answers depending on your users and your system. What is right for one system is wrong for another.
When you’re building a product even the smallest parts require careful planning and design.
We don’t track anything on this website. There is no Google Analytics. We don’t track you with cookies. We don’t generate reports on log files.
We just enjoy sharing things, and want a place to do that.
When we track numbers we often change our behavior to affect those numbers. If we were tracking the number of visits or hits to this site, we would write and publish different things. We would think about the 5 or 500 people reading the site and tone down our arguments, or not share screenshots incase people steal our ideas. We would behave differently.
By not knowing, we are free. Free to do what we like and be creative. To not be scared of publishing half baked ideas or typos.
I have to actively turn on, unlock and look for the red dots on my phone to find out about new messages.
If I want to see if I have new email. I have to open the app and look in it.
There is no longer a constant beeping throughout the day. Or switching on and off of a phone to check the lock screen. Or phantom vibrations from my pocket.
I get to focus on what I’m doing and then when I want to, in my own time, actively check for notifications.
I manage to work uninterrupted for longer periods of time. I’m more focussed on the things I’m doing without constant switching back and forth between different mental tasks. I feel less stressed out and so much more productive.
Most people when they think of great software they think of one or two things: software that makes a lot of money or software that’s technically difficult.
While both of those two properties describe many successful software products, it doesn’t make them great.
What makes software great is consistently.
Good software is consistent with the platform it’s running on. Don’t bring Android-isms to iOS and vice-versa.
Good software is consistent in form. Use the same paddings, margins, and colors. Nobody likes staring at an Easter egg all day.
Good software is consistent in it’s function. Define a pattern for how your tool works and stick to it. This is the most difficult because you often find an edge case later on that requires a small inconsistency with the rest of the system and updating everything to the match new standard takes time and money.
The quest for consistency feels neverending, but it’s the difference between junk and great software.
Kwoosh is a single page app. Meaning that you load a single webpage when you start and then all subsequent clicks just change smaller elements of the screen. This makes the app feel faster as you never have to redraw the whole screen. You never get that “white flash” of the old screen disappearing and the new one appearing.
Requests still however take time. There is no way to get around that. But to make the user feel like the app is faster you can immediately respond to users requests by showing a pre-loaded loading screen. In our case we will show it every time the user triggers a request that goes to the server.
We liked the simplicity of our logo and thought that we could create an animated loading gif to use.
Jacob is based out of Manchester, UK and James is an American currently living in Japan.
We have been slowly working on Kwoosh as a side project for the past 18 months or so.
We have been building software remotely together for close to 20 years. None of the project management/bug tracking/ticket/spreadsheet systems we have tried have fit our flow.
We have always had to change our way of working to fit building software into a pre-defined project managament system. None of them were specific enough for the whole software lifespan of planning, building, launching and maintaining.
We wanted to create a system that was focusedjuston building software…and that isKwoosh
This week we’ve decided to burn down the backend and start over with a fresh approach. While it’s not a total rewrite (we’re reusing a lot of our code: models, database, forms and so forth), we are refactoring and replacing all of our views.
Why? In a phrase - performance and maintainability.
Building a modern UI requires a lot of markup and has many of moving parts. This results in some rather complex templte logic. Rendering these templates are quite slow. When you run into performance issues the typical advice is start caching fragments, allowing you to often skip rendering all together.
We did this and while it improved performance considerabily. However it had a different cost: maintainbility. Starting to cache bits and pieces here and there to eek out a few ms in performance massive increased overall complexity.
Template Complexity + Cache Complexity = Burn the thing down.
We’re about two weeks in to reworking our interface. From the surface you can’t see any visual differences, but under the hood is all new. And boy is it singing.