In this article, we're going to look at Don Norman's design principles that he discusses in his book called The Design of Everyday Things. If you didn't read it already, I fully suggest you check it out. I'm going to discuss the principles and give some examples along the way, but I'm not going into too much detail as that can be found in the book.

Throughout this article, I keep repeating "object" and "artefact". These can be a physical device, a user interface, anything really. I use those terms because the definitions that are discussed below apply to anything.

Performing actions

When using an object, an interface or taking any action, we do it because we set some goals in our mind. Without goals, we wouldn't need to take any actions, right? Taking actions is an iterative process that happen on two dimensions: Execution and Evaluation.

Execution - In this dimension we examine our goals, intent to act, build up a sequence of actions and execute them.

Evaluation - After we completed the actions we notice what has happened, we interpret and lastly evaluate the results which helps us generate new goals and then everything repeats.

A good example that came in my mind now that I was writing this article is the actual keyboard typing. I have the goal to write a sentence, I intend to use the keyboard, I know what I'm going to write and which buttons to press, and then I type everything down. I examine the screen and I evaluate the situation. I notice that I made a spelling mistake in the middle of the sentence and then my new goal will be to correct this. The new sequence of actions will be to click where the mistake is and type the right thing. And this process goes on and on because that's how we function as human beings. This seems pretty obvious, but as designers it helps to think about these basics to create useful interactions that doesn't break the cycle of coming up with new goals.

Conceptual Models

Whenever we want to interact with an object we already have an idea how it works or we can consult the instruction manual to learn more. So how does the conceptual model work when it comes to designing a new artefact?

The designer has his or her conceptual model and the trick is to be mindful of that and make sure that this translates well in how the user conceptualises this. A good example here is an open-source project where the designer/developer created a documentation to unify the creator and user conceptual models. Take a look below at a diagram describing this scenario:

Of course, you might say the documentation example is too much and a good designer should design something that can be easily used without having to write pages of instructions. And you're right to think that! This is where the following come in:

Affordances

This means that the object that is designed should have perceivable actions. The user should be able to look at the object and know how to manipulate it without having to consult the instructions. When a door has a handle on one side and a plate on the other, you know that you can pull and push respectively.

Signifiers

Signifiers are used to indicate certain actions. In the example with the door above, a signifier can be a hand drawn on the plate to indicate that the door can be pushed with the palm. Sometimes it's a bit tricky to distinguish between Signifiers and Affordances. My usual approach is to think about affordances as being the innate properties of the object that can be perceived and signifiers are any perceivable signs that point to how an object can be used. So you can think that signifiers make the affordances more clear.

The signifiers term was added in the latest version of The Design of Everyday Things book. If you're reading an older version you won't find the term described there.

Mapping

This concept refers to the relationship between the actions performed and the results in the world. The mapping should be easily remembered so it becomes obvious the next times the object is used. Another aspect of mapping is that the controls should match the effects in some way. This can be done through shape or positioning (grouping and patterning). Norman gives several examples, but I selected two of them to better explain what I mean by mapping through shape and position.

In terms of shape, Norman gives and example of the seat adjustment controls that are placed in the shape of the seat itself. You can see the example in the image below where the the two buttons that resemble the seat map nicely to the effects you expect as the user - left button controls the lower seat and the one on the right, the back rest.

When looking at the position, I like Norman's example of light switches. For a good mapping the light switches should be grouped by which room they control the lights in and in which order. So let's say you enter a hall and the hall leads directly to the living room. As you enter there are three switches. The first one should be for the hall itself and then the two others should be for the living room in the order in which the lights are placed apart from each other.

Constraints

The constraints are a powerful concept to keep in mind when designing an artefact. They come in multiple shapes and forms, but they basically do what they say - they don't allow users to perform certain actions. Take the scrollbar on the side of this page as an example. You can see where you are on the page and how much you will be able to scroll. You can't scroll more than the top or bottom of the page. Also, since we are on the topic of UI design, the greyed our menu options or buttons are examples of constraints as well. They allow easy communication with the users to let them know certain actions are not possible.

Feedback

So we have a nicely designed artefact that has all the affordances and signifiers in place, it's properly mapped and limits the user from taking the wrong actions with the constraints. Now the user is using the object and something happens. This "something" should be visible to the user so that we can complete the execution evaluation cycle that I talked about above. If the user takes an action and there's no feedback, then the tendency is to try again and then declare the object broken. A button on an interface can have "pushed" and "released" animations and some kind of result should appear on the screen. This could be a loader and a checkmark when the process is complete.

Mistakes happen

Even if all the concepts above are extremely well implemented, the user is bound to make a mistake at some point. As a designer you should prepare for these situations by making sure users can recover from them. The mistakes can happen for a several reasons:

• Lack of knowledge
• Instructions errors
• Losing concentration
• Slips, etc

The user tends to blame themselves when something wrong happens when using the object. So the errors must communicate the situation to let the user know what happened. The designer should design for errors in this case.

It might seem strange, but the design should allow mistakes. The reason being that the mistakes should be there for the user to know what is allowed and what is not in certain situations. Of course, this only works if the user is told that the action was a mistake. Another way is to allow the mistakes, but then ask the user how to proceed, like in the scenario where a user wants to exit a document that wasn't saved. In some cases that can be a mistake, but it can also be on purpose. So to solve that problem the system can display a dialogue asking the user if they would like to save the document before exiting. Another important function for designing for errors is to allow to recover from mistakes. An example can be the undo function.

Bonus: If you want to explore other ways to think about interaction design search for Schneiderman's rules for interaction design. Here is a good article on that

Next time you design an object or an interface try and think about all the concepts above, especially the affordances, signifiers, mapping, constraints and feedback. Or you can even take an existing interface and take it through all of those to see how they check certain things. If you find something interesting feel free to get in touch with me and we can discuss it.

Also, if you haven't done so, feel free to subscribe to the newsletter to know when I post the next article in the series.

Until next time, with more design theory!

-Raz - @razvanilin

This article was based on a lecture by Patric Dahlqvist from KTH University and Don Norman's The Design of Everyday Things book (which I fully recommend for reading).

Cover photo by Firdaus Roslan on Unsplash

In the previous part, I wrote about the visual perception capabilities that we humans have and how important this is for design. We take all the current interface design for granted, although most of them rely on decades of research. Especially since the Gestalt Psychology school was founded at the beginning of the 20th century.

Now let's shift our focus towards our memory and to relevant theories that are guiding the design. Believe it or not, designing for memory is vital in ensuring that your users are not struggling with your product. Again, due to the decades of research in this domain, most of the current designs are doing a good job on this side of things, but the problem comes with more complex systems where you have to keep switching between familiar interface interaction and more specialised use. Let's go to the basics first.

Attention

Attention, as I see it, sits right between perception and memory and has an important role in how we perceive the world. For example, you can look at something, but if you're listening to what somebody from behind is telling you or you are deep in thought, you will most likely not pay attention to what you're looking at. Some people are better than others at dividing attention, but as designers, we should not make these ideal assumptions.

Like I mentioned in the previous article, we are constantly processing a lot of sensory information at any given time. When we are working in an office, we will pay attention to the temperature around us, the voices, notifications, the colleague chewing something near us, etc. We as humans have the capability of having selective attention. This is how we manage to focus on what we want to pay attention to.

There is an interesting effect called the "Cocktail Party Effect" which describes the situation when you look at something, but you pay attention to another thing. Much like at a party when you look at a person, but you concentrate your attention on someone else speaking behind you.

When it comes to design it's fairly difficult to design for attention since you have limited knowledge about the user's capability to maintain a focused state for long. The general rule of thumb is to make sure the user can resume the work at any time as though they lost attention. Thinking about an interface, this could be a visual state of the progress that's been done by the user, so they can safely resume.

You can read some more in-depth theories in the "Cognitive Psychology" book written by Robert Sternberg.

More of an aside, here is a podcast episode from devmode.fm about maintaining focus as a developer.

Memory

Memory comes in three different levels that feed into each other, the sensory stores, short-term store, and long-term store (take a look at the picture below). Attention is part of the sensory memory and this is extremely short-lived in nature. If we stop paying attention to the information at hand, it fades immediately.

Now let's take a look at the other two parts, the short-term and long-term memory.

Short-term memory

Short-term memory or working memory is where we keep the information we need to complete the tasks at hand. The information we keep here usually fades away in around 30 seconds. A good example is a sequence of numbers we use to make the next call. Let's say we have a chat with someone and this person tells us a sequence of 7 numbers to make a phone call right away. This usually works and most people will be able to keep this information in their memory long enough to make the call.

The cognitive psychologist George Miller wrote a famous paper where he discusses the ability of a person to remember 7 ± 2 numbers using their short-term memory. This number can be extended using patterns. Remember in the last article how good people are when it comes to patterns? Well, this is the same when it comes to memory. For example, if we have a series of let's say 16 numbers, but we chunk this into groups of 4 and each group has a meaning for us, then we could actually remember this long sequence quite well.

1980 4687 7734 2514

What are the implications in design when it comes to working memory? As designers, we need to optimise the way the processes work within the application. The first example that comes to mind now is the 2-factor authentication. Let's say you secure your application and decide to send an SMS code to your users when they try to log in. The easiest way for the user is to glimpse in their notifications to see the code and then write it in the verification box on your site. Pay attention that the user will most likely have their phone on the table, locked and with a short on-screen time so writing number after number and checking the screen multiple times is a bit cumbersome. So what are most of the applications doing? They send a very short number, usually ~6. That way most users can remember the number with just one glimpse. Six is still a big number and the safest bet that the user will save the number in their working memory is more like 4.

Long-term memory

Unlike the working memory, long-term memory is basically unlimited in capacity. Our long-term memory stores most of the information in a semantic way so that we can remember facts based on the context or we can even use our senses to pull down memories, for example, using our olfactory senses to recognise the perfume of a loved one or to recognise if food is fresh or not.

On top of the semantic memories, we also have two other types, episodic and procedural. The episodic memories are things that marked us in life such as important achievements and very negative experiences. You know how everybody says that once you learn how to ride a bike you will never forget how to do it? Well, this is the procedural memory at work. This type of memory usually is always accessible in our minds unless a person suffers a severe trauma that can interfere with the memory.

The implication in the design arises when thinking about how people retrieve the information from the long-term memory store. There are two ways that designers in HCI base their designs on - Recognition and Recall. My favourite example to understand these concepts is the one on the Nielson Norman Group's site where it describes the situation when you meet a person on the street, you remember their face, but you think hard and can't remember the name exactly. The first part of the example when you remember their face is the recognition at play and the second, when you want to remember the name is the recall. You can see right away that recognition is a much better way to retrieve information from the memory. Recall requires more time and effort for the person.

Using the information above, we can reach the conclusion that we want to employ recognition as much as possible in our designs so we don't put too much pressure on the user. Recognition is easier because it relies on more cues to help a user retrieve the memory. In the example above, we might've seen the person multiple times, but they didn't mention their name all the time for us to remember (I often forget names because of this). So when designing an interface we rely on common design patterns such as toolbar menus in photo editors with the familiar icons for select, bucket, crop, etc.

Have a more in-depth read about this on Nielson Norman Group's site.

Discussion

In this article, we looked into the inner workings of the mind when it comes to memory. In my HCI journey so far one of the most prominent discussions arising were about the Recognition/Recall. Most designers nowadays try to use elements that users are accustomed to and really keep the user away from having to recall information or to learn new things completely. But I want to start a discussion with you on this.

One can argue that always designing for Recognition can kill innovation. Think about it - what if we're too afraid to come up with new interaction designs and miss out on opportunities to introduce new designs in the industry. Michel Beaudouin-Lafon, one of my professors at Paris Saclay, mentioned that it takes usually around 20 years for an interaction type to move from the lab to the industry. But now I'm thinking, what if designers in the industry will stop taking current interaction designs for granted and become more creative? Do you think this will create chaos in the world of design or everybody will benefit from this? I would love to hear your opinion, so feel free to send a tweet my way and let's discuss!

Catch you next week with another article in the Design Stories series. If you haven't done so, subscribe to the newsletter to know exactly when I post a new story.

-Raz - @razvanilin

This article was based on a lecture by Patric Dahlqvist from KTH University and David Benyon's Designing Interactive Systems book (ch. 21 and 23).

Cover Photo by Valentino Mazzariello on Unsplash

In this article, we're going to take a dive into learning about different human capabilities when it comes to the perception and how it influences the designs we are creating. This article is based on a lecture I had in the beginning of my course in HCI. It will be more theoretical than I planned, but I think it will be useful to get to know different theories, build up on that and then get to play around with some examples. It's funny how when I started studying these I was getting tired of all the theories and now I see the importance of all of them when thinking about design. And this is the point of this series - going back through all the material and extract the most interesting and important bits that I can then build upon and apply later in my projects.

Perception

Even though we as humans can do amazing things with our bare hands, we got where we are today based on our ability to create tools to help us in the day to day life. You will hear this a lot in HCI, but one of the most sophisticated tools we are referring to in this domain is, of course, the computer. Even though there are advancements in different AI algorithms to make computers smarter, at the end of the day the computer is still meant to be used to help humans accomplish goals faster. What I'm trying to get to here is that we have capabilities such as our perception of the world that influences how we create these tools. Knowing more about how we perceive the world means that we can design better tools.

Our perception capability is based on how we gather information from the world. This is done through our senses like vision, hearing, smell, touch and taste.

We are actually processing a lot of data every second:

• With our eyes, 10 million bps
• With our skin, 1 million bps
• With our ears, 100 000 bps
• With our nose, 100 000 bps
• With our tongue, 1000 bps

So in total, our brain's bandwidth is of about 11 million bits/second. Naturally, perception becomes of great importance to HCI and related fields like Human Factors because then the design can take into consideration how humans communicate with the world around them. Since we're concentrating on HCI, we're going to look more into how humans communicate with computers, in particular, and how the design is influenced by this. The main sense we're going to look at is the vision.

Vision

When it comes to vision, we as humans are super good at recognising patterns. Take the image below as an example where you can easily recognise all the letters in the image below as the letter "A" even though the letters vary in size and shapes. The fcat taht yuo cna raed tish aslo prooevs taht hmuans aer cool.

This superpower can also play tricks on us with things in the form of what we call optical illusions. Take the image below as an example. What do you see?

These are all interesting observations because it hints that we can see things better if we group them. If we can't see patterns, it will be hard to understand and navigate the world around us and will create confusion in multiple scenarios. All these observations were the basis of a psychology school that was founded at the beginning of the 20th century called Gestalt Psychology.

Gestalt Psychology

Max Wertheimer, Kurt Koffka, and Wolfgang Köhler founded the Gestalt Psychology school which studied human perception and created a theoretical framework and methodology around it. The theory is based on the following principles:

• The whole is more than the sum of the parts
• The isomorphism principle or the similarity of structures
• The organisational principle

From my experience in HCI, the last principle is the most important one when it comes to design. This principle is split into proximity, similarity, continuity, closure and good form. You might find these under different names depending on what site you stumble upon, but don't worry too much about it as the meaning is the same. So let's see what these mean:

Proximity

Because we're so used to seeing patterns we tend to group items together based on the distance between them. If you look in the image above, you can notice right away 4 pairs of lines instead of 8 lines. To better illustrate this, let's think of a website UI where you group cards to better convey information. In the example below, you can see pricing plans grouped together in a row and then underneath there's more information about member pricing. The way you would read this is influenced by the position of the cards. You will most likely explore the different plans and only then look at the details. On top of this, both sections are close to each other because they both refer to pricing. The rest of the elements on the page are further apart to differentiate themselves from the pricing section.

Similarity

We also tend to group items together by how similar they are with each other. This works in the example above as well. The 3 pricing plans cards all look similar and our brain instantly sees them as a group. The members' section is clearly referring to something other than pricing plans because it looks different. The picture above combines Proximity and Similarity to better convey the information. You might say that this is straightforward and that you do that without thinking about these terms and I 100% believe you. Don't forget that these principles were developed in the first part of the 20th century and website design evolved just "recently". Now all good practices are based on these theories even though most designers don't know about these principles.

Continuity

The best example other than the picture above is a song. When you hear a song you don't hear every single note, you hear the entire melody, the continuity of the notes. In the example above, you don't notice every dot at first, you firstly see two lines intersecting each other. In UI design this is mostly reflected through the proper alignment of items on the page.

Closure and good form

This is mostly reflected in the way we perceive messages from shapes. In the principles picture above, we can clearly notice that the image shows two circles and that one of them is on top of the other. I actually had to think a bit how this can be used in website UI design as I couldn't remember the examples we went through in the class when we covered these principles. Luckily, I found this article by Eleana very interesting to read for more details and examples of how Gestalt principles can be used in website UI design. The closure and good form principles can be reflected by using iconography to convey quick messages on web pages.

Conclusion

Human perception studies were and still are paramount to how Human Factor-related design evolves. The UI design is made for human use and it makes complete sense to know how we perceive different things. We have pattern recognition superpowers and our design should reflect this. I find it very interesting now that I look at all the websites out there and most use Gestalt principles in their design. I don't think this is all due to the studies done in the first part of the 20th century though. I'm a firm believer that even without knowing about these studies we inevitably let our design be guided by how we perceive the UI as we put everything together. Is that enough? Maybe not, I think having theoretical knowledge can help tremendously. And, of course, having the practice takes you on a whole different level.

The next article will explore human memory capabilities and how to design for the different situations. Stay tuned for next Friday and don't forget to subscribe to the newsletter to get a notification when I post a new part in the Design Stories series.

Until next time,

-Raz ✌

Follow me on Twitter if you want to get in touch - DMs are open 📬

Cover Photo by Daniil Kuželev on Unsplash

This blog post was on my mind these past few days and I'm glad to finally pull my thoughts together and write this down. So I have a plan. I'm getting to the end of my classes at University and I was thinking of writing design stories, bi-weekly from now on, based on the knowledge I acquired in 1.5+ years of studying Human-Computer Interaction (HCI). I will graduate from University sometime in September so I selected the first Friday of September to be the last day when I post as part of this series.

The goals of the series

I thought that it's better to share what are my goals, for me and for anyone that wants to follow through as I go through the stories:

📚 I want to better understand and stick the information in my head. I feel that there is so much good information that can help me in the future projects, that I just can't dig in all my notes and material from University to find what I need. This blog format is much more convenient.

✍ I want to get better at writing, both in terms of storytelling and consistency. In the past, I was never able to be consistent with blog posting. In fact, ~16 blog posts is a number way above what I wrote so far in the online medium. I feel that writing is one of the most important skills to have as it's so versatile and I can use it in everything I do in life.

📬 Even though I write these posts primarily for me, I would very much enjoy knowing that what I share here is useful for readers out there to help them build awesome stuff.

What is the content? What is HCI?

"Design" is a very broad term, and in my circle of makers in the tech world, it will most likely mean UI/UX. Well, the content of this blog will be a bit different. It will touch UX, yes, but there will be no UI here. I'm going to talk mostly about the process of designing an interface or a digital product from start to finish. These processes are inspired and/or created by the research activities in HCI.

HCI is quite a vast research domain that focuses on building interfaces and digital products for a well determined user profile and to make this technology simple and accessible for those particular users. So HCI draws from other domains like Psychology and Human Factors.

To give you a better idea, here are some of the themes that I'm going to cover through the stories:

• Discussing Don Norman's principles of design and how looking at doors won't be the same ever again 🚪
• How to power up your brainstorming game and different methods to do so
• How to interview users to get workable data
• Information gathering techniques through observation
• Usability testing (when to use it and when to stay clear of it) and other evaluation methods
• Lo-fi & Hi-fi prototyping
• Video prototyping
• ...and many more

Every story will have examples to nail down all the theory. After getting some concepts out of the way, I will try to write part of the series as a "blog bootcamp" where we start from an idea, then gather information, brainstorm, create scenarios, personas, sketches, lo-fi prototype, video prototype, evaluation, etc. A lot of stuff, but the beauty of it is that you can use whatever you feel it's necessary to design your product. The point of this activity is to make sure that creativity is not killed too early (which happens often and easily, without knowing). But we'll get to that in due time.

Who I am and why HCI

Now that we got the more important stuff out of the way I can present myself, right? 😁

I'm Raz, diagnosed as a geek when it comes to technology, mainly software. I have a background in Computer Science and I started studying it all the way back in high-school. I finished a 4.5 years Software Engineering degree at Napier University in Edinburgh and then decided to pursue HCI and Entrepreneurship in a 2-year Master course. I started this Master course at KTH in Stockholm and then moved to Paris Saclay for the second year. I was contemplating between Data Science and HCI but went with something more different than my previous studies in the end.

It's not obvious straight away, but all this time I studied HCI affected (in a positive way) how I think about digital products or any products for that matter. A good example is Chartbrew, a side-project that I started working on before beginning the Master degree. When I resumed working on it a few months ago I had so many ideas and I could see so many flaws in the way I was interacting with it. I think it's always hard to see the benefits of learning something as you are doing it, especially something very deep as HCI. I lost count of how many times I complained about having to do certain projects during the course, but it's all coming together now.

And with this series, I plan to reflect on everything I learned so far and apply the knowledge once more by writing about it and going through examples.

Writing style

Even though the topic brings concepts from research labs, the blog posts won't be written as though they will be published in a journal. I will concentrate more on my reflections and providing examples than doing a literature review. Of course, I will explain the concepts, provide further reading and give credit when it's due, but the writing style will be more personal and less scientific. I do this for two reasons: I think it's easier to understand in this way and I hate scientific writing, at least I can take a break from that on my own blog. Feedback help as well and I can adjust my style based on it.

I hope you will join this journey and most importantly, I hope this knowledge will prove useful to you. I'm obviously not expecting anything of my readers. All the material here will be 100% free, open to critique and discussion. I guess one thing I can ask for is that if you join me on this journey you have to keep me accountable to post every week ✍

See you all next week with the first story in the series!

-Raz

📧 Feel free to subscribe to my email list so I can let you all know when I post a new story

🐤 I'm also posting more stuff on Twitter these days

📷 Cover photo by The CEO Kid on Unsplash

EDIT: The original goal was to write every week but this took too much of my time and concentration from my personal projects, so I changed it to bi-weekly instead. This will still allow me to cover a lot of ground.

It's due time I start typing away about Chartbrew, a side project that I worked the longest so far. It all started in the summer of 2018 when Kate and I were wondering what to work on through the three hot months. We bounced ideas off each other and then settled on the idea of creating a simple tool for data visualisation. This tool would have to be able to connect to different data sources so that no extra coding was needed.

The important part here is that we didn't need super complex visualisation tools like the ones already available in the market - we just wanted something to help us visualise data from our small side-projects and share them with the world. The final idea was to put the design in the spotlight and leave the functionalities on the 2nd plan.

And because it's hard to work on a nameless project, we had to come up with a name for it. After a few back and forth's we settled on Chartbrew. It had a nice ring to it and we both instantly liked it. Next, because we both have technical backgrounds, we started working on setting up the project and coding different aspects of it.

It's worth mentioning that we wanted to make a business out of this new project, but we took the wrong approach of completely ignoring the validation process. When summer was drawing to an end, we started thinking more and more of how to approach people to see if anyone will be willing to pay for it, but the whole process was alien to both of us.

September was approaching and we were both due to return to studies - a two years Master course. During the first couple of months after we started our course, we began showing the project to online communities and we were getting a lot of positive feedback but nothing worth for validating the business idea. In other words, nobody was hinting that they were willing to pay for the platform. At this stage, we thought the clean design was just attracting eyes and it was easy to receive positive feedback on something that was pleasantly looking.

About this time we received our first $9 for a monthly subscription on the basic paid plan. Unfortunately, this user churned out right after and we couldn't get in touch with the person to find out more about their intentions with our product.

The slumber

It was time to switch the strategies a little. Since we both studied at KTH in Stockholm, we decided to get involved in the entrepreneurship scene over there. We managed to get into several programs meant to help out people that wanted to start businesses. In about the same period we started contacting small companies in Stockholm to try and get a call or a meeting with them to show them Chartbrew. This didn't work that well. We managed to have a meeting with a company but our product was not aligning with how they wished to work with a data visualisation tool. We realised we didn't know who our customer was and this was pretty late int the business and product development cycle.

Our initial goal with Chartbrew was to concentrate on making this into a working business, but it seemed we avoided most of the processes that involved developing the business and concentrated mostly on the product with our tunnelled vision.

A very important lesson here is that it's important to align your goals with what you're willing to do to reach the goals. It's a bit of a backwards approach. If what you do doesn't take you to the goal you had in mind, you start enjoying what you're doing less and less. This culminated with a burnout period where we stopped working on Chartbrew almost entirely.

It was time to switch gears

Time has come to learn from past mistakes. Last time, the goals and actions were not aligned, so a shift was waiting to happen. Since we invested quite a bit of time in getting Chartbrew to this stage we couldn't just leave it like that. Moreover, we received a lot of good feedback before so there was definitely something there.

After the first master year in Stockholm, the degree continued in Paris. This is the time when thoughts about restarting work on Chartbrew started to crawl inside our heads. This time it had to be different. And we thought that since we don't have a clear idea on who our target customer is, let's open our codebase to other people and see what everyone thinks and how they would like to use a project like this.

As I mentioned in an Indiehackers discussion, these are roughly the reasons why we made Chartbrew open-source:

• Some companies don't want to part with their data in any way, so they can run the whole project on their servers
• Companies that run the project on their servers might contribute to the codebase or would require our services
• Extra visibility in the developers' world
• Give back to the open-source community

The Road to open-source wasn't like a snap of the fingers, though. The codebase needed some maintenance. The SaaS elements were also coupled with the rest of the application and these needed to be removed. After 2-3 weeks of working on it (part-time) everything was completed:

• SaaS elements decoupled
• Homepage replaced
• Full-blown documentation is written
• Slack community created
• New repository for the open-source project
• New guidelines for making open releases on GitHub
• Code of conduct for the community around Chartbrew
• Contribution guidelines
• Public roadmap
• Modified the chartbrew.com homepage to reflect all these changes

So as you can see, is not that easy to roll out an open-source project.

The next step was to keep the current SaaS project working. The next piece of work was to make sure the two repositories were synced properly. This was done without too much hassle and now it works like a charm; release updates on the open-source repository > merge changes in the SaaS repository.

Moving to open-source and also keeping the cloud version running puts us in a better position to tailor our services with potential customers and at the same time build something for the whole community of open-source software to use. And now to refer to a point I made above:

The goal is not to create a successful business, the goal now is to create something that people want to use!

I think this is an important lesson. You can have goals, any goals, but as long as you're not willing to direct your actions towards achieving that, it makes no sense to pursue it and you should analyse how you can turn it around. If the goals are aligned with what you're willing to do to achieve those goals, then you're in the right spot!

And that's what I think about the current state of affairs with Chartbrew. I actually enjoy working on it and telling people about the project. I started streaming the development over on Twitch and I'm super thrilled that most of the people that drop by are amazed by the project and happy to know it's an open-source codebase that the could contribute to.

Chartbrew will represent a big shift in how we think about specialised software like in this case, a data visualisation tool. All this design knowledge from HCI and interaction design research will contribute a lot to the direction where Chartbrew is going and we hope you'll join us and witness it. 👋

This is just the beginning of the story of Chartbrew. If you want me to keep you posted with the latest learnings, designs and frustrations of building this product, subscribe below and/or give me a follow using the links below.

🐥 I tweet here: @razvanilin

📹 I stream here: RAZvanilin

💬 Join our Discord

🏡 Join our Chartbrew Slack

This whole journey of me launching an app started with a one week challenge to develop and release an app in a week. The app is called Hummi.nz, where people can hum songs for others to guess. A very simple concept, but it proved to be an entertaining idea for many people.

Highlights

🚀 Launched on Hacker News and reached #9 in the main section and #1 in the show section

🚀 Launched on Product Hunt, received 80 upvotes and was featured on the main page for most of the day

👥 502 user accounts

🔻 705 app downloads

⭐ 17 reviews with a total of 3.9 ⭐

🍏 30 people interested in the iOS version (will try to have a June release for iOS)

📈 Over 100 users using the app every day

🎤 499 songs hummed

👨‍💻 10 updates

Getting the app noticed with the website

To create the initial traction, I created a website to showcase the app and add buttons for downloading for subscribing to news. The website address is exactly like the app name, Hummi.nz. I wanted to keep this consistent across web and native OS. I’m not sure if this will help me SEO-wise, but it was worth a shot and I liked the name. I posted this on a couple of subreddits and on Hacker News, generating a spike in app downloads and website traffic as seen below:

The first spike was caused by getting to the top of the show section and 9th on the main page in Hacker News. The second spike, there in the middle, was the launch on Product Hunt. Not as successful as HN, but quite good nonetheless. The total number of unique user sessions on the website this month was 1501.

Play Store metrics

In the beginning, the same story as with the website. I’ve seen spikes in downloads at the same times as above, coinciding with the HN and PH launches. The successful launch on HN resulted in about 140 new installs in the space of two days.

Interesting to note that in-between the Hacker News post and the next spike at the end of the graph, I actually did post the app on multiple subreddits, xda forums and Facebook groups, but nothing seemed to help me get more downloads. It was sitting on a stable 2–3 downloads/day, but then I read more about App Store Optimisation (ASO) and how it’s a very good practice to identify keywords that can get your app in front of potential users organically on the store.

Play Store ASO

The best decision was to document myself more on the ASO best practices. I identified keywords that work best with Hummi.nz like humming, song, sing, social, community, guessing and so on. One nice way to identify these keywords is to also research what keywords other apps that you want to associate yours with are using. So, for example, I inspired myself while re-writing the description from apps like Smule, Shazam, SoundHound, etc. The results? You can see those on the chart above or you can have a look at the spike in daily, weekly and monthly users below.

Challenges

The main two challenges:

• Developing Hummi.nz and launching it in the space of a week
• Maintaining focus while for the most of the month I was getting only ~3 downloads/day

The first challenge was described more in-depth in my previous post and it gave me a boost in confidence to finally release something and not abandoning it like most of my side hustles.

The second challenge was a bit more painful. The curious thing is that I wasn’t actually planning on continuing with the development of the app, but since it was received so well on Hacker News, it gave me hope that the app could turn into something bigger than I imagined. It was a slow disappointment afterwards as the downloads were going down dramatically even though I was releasing nice new features that some people requested.

Next month’s plans and goals

• Introduce filtering on song genres
• Introduce a support program where users could support me to develop the app and can feedback on features they would like to see in the app
• Optimise my database queries and API
• Introduce user profiles
• Add an achievement system
• Reach 5000+ downloads
• Maintain a review score of 4+ ⭐

Feel like humming some songs? Get hummi.nz from the Play Store ✌

I post updates regularly on my Twitter so make sure you give @razvanilin a follow if you’re interested in keeping up-to-date with news about Hummi.nz and other techy stuff.

It was close to 10pm in Edinburgh, UK, I was resting in my bed typing away on my laptop. Just a few days before I launched my first app called Hummi.nz that I developed for myself as part of a personal challenge. I knew about the show section in Hacker News(HN) and I though I will give it a shot and I posted a link to the Play Store page there. The app is about humming songs and I though maybe people will laugh at it or something along those lines, but I gave it a shot anyway. About half an hour later I received a couple of positive comments which was more than I expected. So I went to sleep with a smile on my face.

Morning

The alarm started ringing, time to wake up. I picked up the phone to stop the alarm, I look on the screen and I see over a dozen notifications from my app. Wow, people are actually using it. I went in my app to check the leader-board (a quick way to see the number of users) and there were over 40 users. Prior to that I had about 10. I jumped out of bed, went to my desk and I went quickly to my article on HN.

I was #10 in the list and I had lots of great comments and suggestions. Wait, oh no, some people complaining that they can’t log in. This can’t be…

Technical issues

Of course nothing can go well especially when your API, database and mobile app were developed and designed in a week. Fired up my terminal, accessed my server, listed all my Node services running there and, weird, everything was up and running. Checked the logs, database failures, unique constraints errors on the username field. Basically and technically:

• The app was creating users without a username field
• The username field was being populated on the next on-boarding screen in the app (very clever design, indeed)
• Someone left the app without selecting a username
• His username field was null
• All the other users trying to register couldn’t because it was restricted to have another user with a null username
• Seriously, Raz?!

So that was a disappointment. It happened while the app was getting a lot of attention from the HN community so I probably let down quite a few people. Problem patched, now time to check stats. Obviously, the site views went up quite a bit, but what got me excited the most, was refreshing the leader-board screen on my app and see how the number of users was going up, 45, 50, 60.

The Unexpected

I didn’t expect my post will get so much attention, and really, I was thinking that I might maybe get about 4–5 comments so I get to know a bit more about what people would like to have in a humming app like this.

Going back to the roots of the project, Hummi.nz was developed and launched in a week, there was almost no time for market validation, getting feedback from potential users and any other processes that could’ve helped me release a polished app with the perfect features. I basically developed and designed the app as it was pictured in my mind and released it into the wild. Then I visited the Play Store dashboard…

Two 1 star ratings. This brought my app’s rating at 3.something stars. After a bit of time I was slammed again with a 1 star rating, but luckily I was also getting 5-star ones to keep the rating above 3. One of the low ratings was from a user that couldn’t log in because of my server problem. Fair enough, I fully deserved that. But what was most interesting was that I got two 1-star ratings because I would allow users to use the app only after they log in. People didn’t like this and some of the discussion on HN was related to this as well.

I replied to the users on Play Store letting them know that I’m going to modify Hummi.nz to not require a login for access. I took this idea to the board and reached the conclusion that it is indeed a good point and I’m grateful to have received the feedback.

• Users can get into the app more easily just by entering a username
• They get the option to make an account so they safely use the app on other devices
• The whole on-boarding process becomes much easier

Going forward

This is all very exciting for me. I worked on multiple projects that had many users before, but it was never one of my own projects. I guess now I’m going to work more than I expected on Hummi.nz because of all the great feedback I received so far. The new on-boarding experience is already released and I have many other great features on the list.

I’m going to end this post here, but I will come back with more from my journey with Hummi.nz and any other side-projects I’m working on at the moment. Catch you all next time!

I try to post about my progress more often on my Twitter. You can give me a follow at https://twitter.com/razvanilin

One app, one week, no procrastination, no perfectionism, just launch something and see how it goes. Don’t go into the developer mindset of regurgitating features that maybe people will not even want. Just the essential, and get to work, fast.

Short background story

I always loved the idea of making products and I even made a few, but looking back to them, I see a pattern. I never actually launched them. I am 100% sure that because I have a technical background, I get way too excited about the technology I’m using to build an idea rather than about the idea itself.

So I need to train myself, my mind, to think business and use my time efficiently. Normally, before starting to develop a full-fledged application you would identify and consult with your target market, ask questions here and there to see if people want your product and eventually build a simple MVP to take the idea validation to the next step. For now, let’s concentrate on that simple MVP part, the initial validation can be done with my next project. Baby steps, right?

The idea

One evening I was walking home with my girlfriend and she started humming a song and we couldn’t put a name on it. I thought of Shazam, but nah, the app couldn’t detect the song if you hum it. So the idea instantly hit me. What if instead of using fancy technology to detect songs, I create an app where you can record yourself while humming the song and then other users will tell you what song it is. Well, it’s a good idea as such, but how often will people forget songs like that? Not that often, so this won’t be able to attract a big community of users. So then, I will just make it like a guessing game. You hum a song that you already know and see if other people will guess. They get points if they guess, there will also be a leader-board and people will compete with each other.

Done, found the idea.

Drawing Board

• Trello Board
• Architecture design
• Choosing technology stack
• Minimal features and design — strictly necessary
• Name the app

Hmm, I need to be efficient — no drawings. I first started with a trello board and made a list of must-have features that were on the top of my head. I had to keep it simple because I told myself I only have a week to do it. Fellow devs out there will understand me here and will know that a usable app that actually does something will take more than a week to develop and launch.

I roughly sketched the user path and thought of services that I can use to make this happen. Architecture design, no problem, I do this every day. Even though I was tempted by dark thoughts of scalability, optimisation, military-grade security and other similar things, I didn’t give in. Come on, Raz, concentrate, just a simple humming app.

I chose React Native as the main framework to write the application in. I used this on multiple projects in the past 3 years so it does make sense to go with what I’m familiar with. It will also be easy to port it to iOS after I try it out with Android users. I will need easy portability for when the app goes viral, right? *wink*.

I will then develop a small service in NodeJs connected to a MongoDB database. The back-end service will take care of all the data transfers and authentication. I also needed a way to monetise this somehow because as a maker, it will be cool to get something out of it other than experience. The obvious and simple way was to serve ads and make the app free to use with an optional “pay to get rid of the ads” in-app purchase.

To come up with a name for the app, I accessed any possible online name generator out there and eventually, after combining multiple options from these sites, I came up with humminz. The hummi.nz domain was available as well, which was good.

Let the development begin

• 4 days of full development
• Used React Native to develop the app
• Invested quite a bit of time to integrate notifications

So I have a bit of experience developing apps and services. This helped me set up everything quickly. React Native app, MongoDB with NodeJS API, and React app for the hummi.nz landing page. Boom, created a repository for each one of them, structured each project and started hacking around with the mobile app and API in parallel.

The good thing about React Native is that if you have the grips on it, you can hack something very fast. There is a module for everything out there in the open-source world. The problem comes when you haven’t used it before. I would say React Native has a steep learning curve compared to other frameworks out there like Ionic, Apache Cordova and Xamarin. But hey, this is my opinion so don’t take it for granted. Part of why it might be difficult to get your head around React Native is the vast amount of articles about best practices out there that can eat your brain alive if you’re not careful.

I think the hardest and most time-consuming part of the development was when I integrated the push notification system. I used Google’s Firebase Cloud Messaging for this with a cool react native module, react-native-fcm. It took about a day from my productive one week sprint. The way I designed hummi.nz is if a user records and send out a hum, all the other users will receive a notification. This needs a bit of control since you don’t want to receive notifications non-stop. I wanted to control this somehow, so what I did was let my NodeJS service handle the push notifications. The users will be able to control the frequency they want to receive these.

Time to test the waters

• Develop a simple landing page
• Include an email signup to gather interest
• Identify some places where to publish it

After about 4 days of development, I started working on a landing page in React. It was something simple that took me about 2–3 hours to put in place. The first iteration looked like the following:

People like to visualise things, so I placed a screenshot of the on-boarding screen and explained in a few words what the app was about. I also added a waiting list so people can enter their emails and get notified when I launch the app. I posted the link in a few places like reddit and indiehackers.com and by the end of the day I had 8 signups. Eight is not a big number, but I was very happy with that. Even after I got the first signup I was in heaven. I also received valuable feedback and made me rethink some process I already developed. For example, I was planning to force the user to watch a promotional video if they wanted to record a hum in less than 10 minutes after the previous one. I received good advice that a “feature” like that will most likely break the user experience and will slow down community growth.

I highly recommend to anyone that is building something or thinking of doing so, to go out there and talk with people. It’s incredible how useful this is because you don’t build something just for yourself. You want other people to use this, so go and talk with them. It’s not that easy, it takes time to find the right places where you can speak about it and it takes time to write about your idea. It is definitely more boring than writing code, but it is definitely one of the most important things you can do as a maker.

Wrapping up the development

• Final development sprint
• Hurdles with making the final build

Now that I got some feedback about the app, I was ready to resume my favourite activity — writing code. Oh, actually, this is where I stopped the progress for a couple of days because I had other places to be. Ok, then two days later I resumed the work on hummi.nz. I had another two days to code and get the app launched.

The development went smoothly until it came to the building part. I had to build the app for release and Google just released an update for Google Play Services (this is a package that is used by some of the React Native modules). I only released iOS apps before, so I was a beginner to these issues. Apparently, you can have just one version of Google Play Services in your project, so if a module requires version 11.8.0 and another one 12.0.0, then your build will fail. If you face the same issue, this medium post is the closest that got me to the solution. Although, I had to do some extra things, but this is not the point of the post I’m making here.

I was already fatigued from all the constant coding and this was definitely not something I wanted to deal with. Eventually, after hours of googling and trying all the methods that miraculously worked for others but not for me, I managed to force all the react native modules to use the same version. *Rage levels went down*

Ok, almost there, I have the APK, finally I could touch (click) the product of my hard work! Time to test it on my phone, oh snap! Forgot to change the flags in my settings file to direct the connections from localhost to my server. Done, building…installing…successfully connects to my servers, oh snap! Forgot to change the Facebook credentials to my production app. Ok, you get the idea, there were a lot of these events until I eventually managed to build the final package, ready to be published on the Play Store.

The Launch 🚀

• Release on the Play Store
• Tell people about it
• Long wait (not really)
• Getting first users on board

This part went smoothly without any problems, other than the fact that no people were getting the app for the first painful half a day with the app on the store.

I had to make the app look pro on the Play Store, so I made some mock-ups with screenshots from the app, wrote some things about the app with my limited writing skills, and there it was, something I built, out there, available for anyone to download and use. This was a great feeling, but it shortly got eclipsed by the dreadful wait for users to join. Even though I went back to those sites where I initially told people about the app and emailing people that showed interest, no one would join. I was even receiving good feedback and some enthusiastic “yay! it’s out” replies, they were still not joining.

Hmm, maybe everybody has an iOS device nowadays? What can be wrong? You get the idea, I was a bit let down by this, but I guess it’s normal when you were so positively developing something for a while.

Then something happened:

Woohoo! Users downloading the app, and they even recorded and sent hums — best feeling in the world!

Well the number eventually stopped at about 9 new users by the end of the day, but for me that was an achievement. The next morning, 11, even better!

If you have a play with hummi.nz, let me know what you think.

Final Thoughts

This was an incredible journey and a very good exercise for my developer mind. I now think more about where can I go and reach people that would want to use the app, rather than what features I can implement next. While implementing features is vital, it’s not that useful if people don’t want them or there are no users that can actually take advantage of them.

So go out there, build your idea, but please, don’t spend months developing something that people don’t have a need for. Use your time more effectively, engage with other people, learn, prototype and launch quickly.

I also make this article the start of my writings about the projects I develop and what hurdles I experience along the way. Give me a follow and be notified when I post something new. And don’t forget to press that 👏 button to give me a boost of motivation if you enjoyed reading this. Until next time!

Update 8th of May 2020

The method below may not be needed anymore. All you have to do now is to use electron-builder and place a short script in your package.json.

npm install --save-dev electron-builder

And then add the following code in your package.json scripts:

"postinstall": "electron-builder install-app-deps"

Introduction

A few months ago I ran into some problems when I tried to use Sequelize with sqlite3 inside an Electron app. Even though I installed everything properly, I was getting this error:

Uncaught Error: The dialect sqlite is not supported. (Error: Please install sqlite3 package manually)

I was able to fix this using this website but it appears to be down now. I decided to write down the method here and also adding a bit more details on how to solve the problem.

Solution

Go to node_modules/sequelize/lib/dialects/sqlite/connection-manager.js and identify the MODULE_NOT_FOUND error code. Log the error with a console.log(err) before the error is thrown.

Run the application and you will get a more detailed error:
{ Error: Cannot find module 'C:\Users\user\Documents\devStuff\work\app\server\node_modules\sqlite3\lib\binding\electron-v4.1-win32-x64\node_sqlite3.node'

Note the electron-v4.1-win32-x64. You might have something different depending on the electron version you installed

Update and run the following commands to make this work:

cd node_modules/sqlite3 && npm install nan

node-gyp configure --module_name=node_sqlite3 --module_path=../lib/binding/electron-v4.1-win32-x64

node-gyp build --target=4.1.4 --arch=x64 --target_platform=win32 --dist-url=https://atom.io/download/atom-shell --module_name=node_sqlite3 --module_path=../lib/binding/electron-v4.1-win32-x64

--module_path replace with what you got from the MODULE_NOT_FOUND error
--target_platform win32, darwin or linux
--arch x64 or ia32
--target the version of electron you are using

If there are issues on Windows about MSB4019, check this issue https://github.com/brianmcd/contextify/issues/96

That's all

By following the steps above I managed to make the configuration work on Windows and Mac. Hopefully this solves the problem for you too.

If you still encounter the problem, check this post on stackoverflow. It offers multiple approaches.

You probably heard this before or read about it in a blog somewhere. A lot of people recommend waking up in the morning because it gives your day a boost. Well, I actually started doing this for the past 3 weeks and I will describe my experience about it. I won't go over all the general benefits of waking up early because you can find that all over the Internet (I will leave some links at the end of the post).

Productivity

As the title says, productivity is one of the first motivation to wake up early in the morning. I work a lot on side projects and I am in need of some productive coding sessions when I'm home. Before, I used to go to sleep at around 1-2am and wake up just in time to make some food and get to work in time. I was procrastinating a lot during my evening coding sessions.

Typically I was "working" from 7-8pm to around 12am. I say "working" because half of the time I was scrolling through Facebook, watching Youtube videos and many other things that were not classified as productive.

So how does waking up early affect productivity? In my experience, I found out that after work, my brain was quite tired. My concentration levels were not as high as during the day and that's why I found it so easy to drift into procrastination. At 5:30am in the morning I have an unpolluted fresh mind that helps me to be productive.

Longer Days

Theoretically, the days are not longer for me but if I wake up early, I'm under the impression that they actually are. Before, I used to sleep after 1am and wake up at around 7am. Now I go to sleep at 11pm and wake up around 5:30am. The amount of hours I sleep is about the same.

The problem is with not valuing the time properly. If I procrastinate I later thing that was all a waste of time when I could have been doing some more important stuff. Doing something I'm later grateful of, make my day more meaningful and I feel like I achieved a lot in a day hence the 'length' seems longer.

Quality time - Quiet time

I feel like I own the world when I wake up early! I feel super excited to get on with my things and enjoy the morning silence while doing so. Currently, I live in a shared flat and even if my flatmates are quiet, I still feel their presence in the house. Early morning? Nothing. And I like nothing, I like hearing the wind, the seagulls and people rushing with their cars in the distance.

The morning meal

Breakfast is the most important meal of the day because it gives you the much needed energy your brain and body needs for facing the day. I started eating a lot in the morning some time ago and I can confirm these benefits. When I get to work my mind is not thinking what will I have during lunch. I'm also really productive and do things much quicker and without mistakes.

Waking up early gives you enough time to pay attention on what you're eating. You can cook something nice. I enjoy cooking and mornings are great for that.

Going to work prepared and in time

Before I started waking up early, I was rushing through making breakfast, having quick shower, ironing clothes and the running to work. Sometimes I was having just a tiny breakfast because I was running out of time. These things affect your mood. I found it better to have plenty of time in the morning to do all these and go to work relaxed.

Now that I wake up early I even have time to plan my day out. What exactly I will concentrate on at work, what will I do when I get back home, and so on. This saves me time later on and make me more confident.

Conclusion

Waking up early is one of the best decisions I took lately. I feel good that I finally have time to concentrate on my own projects and be productive at work at the same time. I want to experiment some more with this and I will give you updates through emails so feel free to subscribe at the bottom of the page. One thing I want to try soon is to go running for about 20 minutes as soon as I wake up.

If you think your not productive enough during the day, I recommend you try waking up early and see if that boosts your productivity.

Promised links:

This is Why Productive People Always Wake Up So Early

Benefits of Early Risers

Why Breakfast Is the Most Important Meal of the Day

Create Your Morning Routine

ofxAwesomiumPlus is an addon for openFrameworks. It works as an interface between Awesomium and openFrameworks. This addon was built on top of an existing one (ofxAwesomium) because it was too limited to use it for the project I was working on at the moment. This addon gives you the ability to easily set up an interface for your application using HTML and make it interact with you c++ codebase. In the picture above you can see how you can combine openFrameworks elements with the HTML UI.

Technologies Overview

openFrameworks

This is an open source c++ framework with a lot of features aimed towards creative applications. I use this framework to work with OpenCV for the Computer Vision technology. Read more about this framework on their website and give it a shot. I found it really easy to work with and the community is great.

Awesomium

Awesomium helps you build really nice interfaces using HTML, but what I like more about it is that you can bind c++ to javascript functions. You can also execute javascript straight from c++ and get JSON objects that you can use in your application. This all sounds really amazing, but I still find Awesomium a bit underdeveloped and apparently it doesn't seem like it's being maintained anymore. Also, if you plan to use cool CSS3 features, you might be a bit disappointed as not all of them work.

Clone it from GitHub

About

Nebulae is a multiplayer space shooter game that I developed for educational purposes. I always wanted to learn how to develop using the Unity3D engine, and creating an actual game from scratch was the best way to do it. The game was developed in a 2-week period and was submitted to a contest, The Space Cowboy Game Jam. It wasn't a winning entry, but it gave me the necessary motivation to keep working on the game.

Technology

The game was developed entirely using the Unity3D engine alongside their awesome editor. It was really fun to have a graphical interface to look at when you are writing code and see the changes you make in real-time, rather than compiling your code after each modification and wait for it to build. The game is also multiplayer and it was my first try in doing something like that. It was a really fun experience, but a bit frustrating at time, I must admit. Coding it for multiplayer involves a lot of changes in the architecture, making sure the information is sent to all the players so that everybody sees the same things and all the hits are registered accordingly.

The models used in the game were all taken from Unity's samples as my graphical design skills are not nowhere high enough to create my own models. Also the sound effects were taken from 3rd party websites. The effects that I have created are found in the ships's engine, lasers and space dust. These are all particles that have a specific algorithm in place to make them move.

There is a a bigger post that I've written when I first developed the game. Feel free to check it out.

I have been missing for a while, but now I'm back with new material to write about. I finished the 2nd year of uni almost a month ago so now all I can do is wait for my internship which starts in about 3 weeks, so it's good that I stumbled upon Unity.

Unity is a really cool game engine which I wanted to learn a while ago, but had no time to do that. Less than two weeks ago I decided to go back to it and I started doing a  project tutorial that I found on unity's learning space (the tutorials area is really good). From the moment I began the tutorial I was hooked into it ... it was so amazing, waaaay better than playing an actual game. The Unity's editor is just perfect; you can see what you are modifying real-time, you can place objects in the world using a neat interface, you can write scripts to determine your objects' behaviour and modify your public variables directly from the editor, you can reference other objects just by dragging and dropping the object in the right space.

Unity has a good way of reducing the amount of code you write for your game. Don't get me wrong, I like coding a lot, but Unity feels like a breath of fresh air, you don't have to play-test every time you make a modification to an object's position for example, you can just see it in the editor from every angle. The learning curve of the editor is not steep at all. It feels natural to drag objects around, import new assets, add components to your objects, etc. Of course, there are some more complicated things but 99% you will find something about it on the Internet that will help you understand.

So as you have probably guessed I quite like using this engine. I can't remember finding something bad about it in the short time I've been using it, but probably that's bound to happen at some point because, come on, nothing is perfect. For a hobbyist like me, this is a perfect environment where I can have some fun building games. What I like most about it is that you can make a good looking simple game really fast. You can place lights, make some atmosphere with a bit of fog, add some ambient light so the shadows are not completely dark, add 3D sounds and put an audio listener to your character so you can hear the sounds from your character's perspective. These things are just so amazing for an amateur like me.

After finishing the first tutorial (which you can find here) I started another one but half-way through it I was like...meh! don't want to do tutorials anymore, time to do my own stuff. And that was a good decision because you learn faster by doing it on your own...well not completely on your own, I mean with your friend Mr. Google helping you out. I started working on a game called Nebulae which is a multiplayer 3rd person space simulator. As a beginner I think I progressed really fast with it because in less than a week I managed to implement quite a lot of features. The thing I am most proud of is that I managed to implement multiplayer as that was a first in my short game development journey.

Have a look at how Nebulae looks by watching the video below:

http://www.youtube.com/watch?v=qFP8F5TpF2g

If you like developing games and you never tried Unity, I really recommend it so give it a shot, it's free!

I think I'm suffering from Unity hype right now *coughs*.