*****************        Hey! Welcome to the Kwoosh Workshop
     *******************       -----------------------------------
    *******  *****  *****
   ********  ****  *******     This is where we talk about the things
  *********  ***  *********    we're working on.
 **********  **  ***********
***********     *************  Most things start as messy ideas before
 **********  **  ***********   they get polished into finished features.
  *********  ***  *********
   ********  ****  *******     This is a place for messy ideas.
    *******  *****  *****
     *******************       For the completed product see kwoosh.com


Remove all the friction

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.


But does it help your users?

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.


The hardest part

People say that programming is hard. But it’s not. Programming is easy.

What’s hard is figuring out what you need to do to make your idea a reality.

Breaking down the idea into a specification. Designing the data structures. Planning an interface. It’s all difficult work and requires great concentration and consideration.

As you implement your program you’ll inevitably find edge cases that you didn’t plan for or as a result of a requirement change.

The hardest part about programming is admitting that your plans, the ones you spent so much effort and time on, didn’t hold up to the requirement changes and then doubling back to fix it.


Changing posting habits

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.


Not telling anybody

We have yet to tell anybody about the Workshop.

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.


But can they understand?

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.

kwoosh task list


Tweaking it all

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.


Starting to get back on track

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.

Time to now move onto the next change.


I'm a lazy programmer

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.


Take a break

Not many people talk about taking breaks.

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.


Overview of a login

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 “jacob@kwoosh.co” instead of “jacob@kwoosh.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.

kwoosh login screens


Do it for the views

Or don’t.

Do it because you like doing it.

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.


Turn off the notifications

I turned off all notifications last month.

All popups. All sounds. All vibrations.

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.


We hardly knew yee

When you’re first building a product, you don’t know what it will do or be yet. You have some ideas that sound good, but you can’t be sure until you actually try it.

As your product matures some of the decisions you made earlier, no longer make sense. You have two options: leave them in and let them rot or pull them out.

Pulling them out and refactoring properly takes time. As part of our migration to Vue, we have the opportunity to revisit some areas that just don’t make sense anymore in Kwoosh.

Our quick add button is on the chopping block. We originally envisioned this being the primary way of adding tasks and screens in Kwoosh. But once we got inline adding, we no longer used it.

As pretty as the animation is, it no longer makes sense in the product and is being removed.

RIP Quick Add. We hardly knew yee.

Quick add example


Do it for yourself

Sometimes it’s nice to just do things for yourself.

Don’t worry if it doesn’t fit into your grand plan. Don’t worry that it doesn’t make you money. Don’t worry that it doesn’t get likes or shares or views.

Just do it because you want to.

Treat yourself.


The secret to great software

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.


It's becoming a big release

Two weeks since we started to convert Kwoosh over from a fully server based rendering system, to client based rendering with Vue.js.

Lots of work completed and lots still to go, but with over 200 commits in the new branch we are on the home stretch.

202 commits ahead of master


Things are faster with a loader...

…or at least they give the impression they are.

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.

It turned out like this:

Design process of the loader


A new logo

It’s always nice to have a logo when starting a new project.

It’s like giving things a name…once they have one they feel more real.

Here is what we have for Kwoosh:

Kwoosh logo

We didn’t want anything too complicated, so a simple hexagon with the letter ‘K’ is good enough to begin with.

It works well at a small favicon size, as well as at larger sizes where we can add some more graphical flurishes such as curves.

It also works well in any colour (and inverted) so we will easily be able to use it on the app and emails/social media etc.


Mind the gap

When we’re deep into a problem we don’t stop and document things properly because it doesn’t feel like progress.

That hard earned knowledge and missteps along the way is soon internalized and becomes just something we know and therefore obvious. However what is obvious for you may not be obvious for others.

Stopping to document along the way helps bridge the gap for other people, or even yourself in 6 months.

Mind the (knowledge) gap.


Why a text based design?

We talk about design a lot. We love great looking sites and we also love ones that are designed to work incredibly well.

The issue with a pixel perfect fancy designed site is the same issue that a lot of people have with shiney new things…they are afaid to get them scratched and dirty.

So the reason why we wanted this site to be a simple basic e-zine style is so that we don’t get scared to post.

We want to show the real build process…and it’s messy. If we were usign Medium or a fancy wordpress template, we would be less likely to post imperfect screenshots and half baked ideas.

The lack of design gives us the freedom to use this as a true workshop where we can try things out, experiement and iterate on ideas.


New monitor

Finally got a new external monitor after the move to Japan.

This should make codingmucheasier.

new monitor


Getting you up to speed

Since this workshop is new and many people won’t know what we are doing..let’s answer some quick questions about what we’re doing.


We are building a software project managament system calledKwoosh.

It is an online SaaS system that allows you to plan, build and maintain software…specifically website, web apps and mobile apps.


There are two of us.Jacob WykeandJames Van Dyne


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


Burning it to the ground

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.

Performance is a feature.


Welcome to the Workshop

This is a place where we want to talk about ideas and show off unfinished, messy, broken, imperfect things we are working on.

We want to show what comes before finished.

We don’t want to show pixel perfect finished designs that stand alone without explaination.

We want to show the 99 designs that come before that stage.

We want to show the decisions behind why we did things. We may try lots of different things, but why did we settle on this one final design choice?

We hope to show the progress from idea to completion.

This is our workshop.