Mounting folders in DOSBox during Boot

Here is a quick fix to a chicken-egg problem: You need to run the mount command to mount folders in DOSbox, e.g., to set up your C:\ drive. Usually, you would run the mount command from your AUTOEXEC.BAT – but the “drive” where your AUTOEXEC.BAT is located is not mounted yet because you did not mount it yet.

The solution is to use the [config] section of your DOSBox .ini file:

install = mount.com c ~/Documents/DOS > NUL

The INSTALL command loads drivers during boot time.

This allows you to run the mount command and set up your C drive first.

Now, you can also add an AUTOEXEC.BAT to the “boot folder” and execute this. Add the following section to your DOSBox .ini file:

[autoexec]
@echo off
call c:\autoexec.bat

Now you have a mounted C drive and an AUTOEXEC.BAT as you would have in regular DOS.

Persistent Command History for 4DOS / DOSBox

  |  | 

One thing I like about bash-style shells is the possibility to go back through my command history – even across sessions. 4DOS (which I use in DOSBox-X) can also be configured to keep a history, but it is empty when a new session is started.

Unfortunately, I could not find a solution for this online.
So I had to come up with a fix for this:

Add this to your 4DOS.INI or the [4DOS] section of your DOSBox .INI file:

History = 768
HistLogOn = Yes
HistLogName = C:\TOOLS\4DOS\4DOSHLOG

This will activate logging.

 

Next, add this to your AUTOEXEC.BAT:

history /R C:\TOOLS\4DOS\4DOSHLOG

This will add your history log to the log memory.

 

Lastly, consider adding this alias to your 4START.BTM (this is where my aliases are stored):

alias delhist = history /f ^ del c:\tools\4dos\4DOSHLOG /q

This  alias will clear your history and empty your history log file:

Now you have a persistent command history in 4DOS / your DOSbox installation.

UX Design is a Craft

 

UX design is a craft, and like any craft, it needs practice and real-life experience. Without practice, you are just playing at UX design. There is no substitute for hands-on, practical experience.

Nowadays, it’s easy to learn the lingo and the approach of user experience design. Just take a couple of (online) courses and read a few books. This teaches you the basics – so you are told. Unfortunately, this will not turn you into a UX designer.

Mock projects demonstrate your grasp of the UX design process and your ability to apply design methods. They highlight your foundational knowledge and showcase your initial skills. However, mock projects alone can’t replace the invaluable insights gained from real-world, practical experiences.

Product development is a team sport, and user experience design cannot be practiced alone. UX designers are part of a larger team – their work contributes to a larger whole. The negotiations, back and forth, learning from mistakes, and iterations are essential and vital aspects of the job. You just can’t fake, skip, or do these things alone.

You need both theoretical knowledge and practical experience. Only real-world work will provide practical experience. A craft needs practice and grows through experience, and you’ll grow with it too.

This is not a chicken-or-egg situation, and I am not saying that you must be a designer to become one. Getting the theory right is a good starting point, but “learn this process and try it out by yourself” will only get you so far.

To truly become a UX designer, you need real practice. Courses are a great first step, providing a solid theoretical foundation. They can help you get started in user experience design, but you need to keep going and practice UX design in the real world.

Get an internship, land your first job, or shadow some experienced UX designers. Work with developers, preferably as part of a team, on actual products. Learn with and from others, and always seek feedback.

Practice the craft.

 

 

Start with Research?

Let’s be mindful about the place and role of user research.

Back in 2011, Don Norman published an article on user research that generated strong pushback. There, he questioned the conventional UX design process in which research is always the first step before creating a concept. “Start with Research“ is the mantra that young UX designers often enter the workforce with. But does research always come first outside academia?

The reality of UX practice suggests otherwise. Activities such as research and testing are often pushed aside for production work. In the real world, creating solutions often takes precedence over activities aimed at understanding and learning. This is a major cause of frustration and lamentation by UX designers.

Instead of waiting for the perfect project, we as UX designers need to adjust our ideal process to match the real world. We must accept that there might not always be enough time to do upfront research. But this does not mean that we have to give up on it. We need to rethink our process to reflect reality.

In most projects, you won’t start from scratch. Review the existing solution. Look for problems, shortcomings, and obstacles. Then create an initial concept. Combine your input with that of others. Be mindful of the facts and assumptions that guide your design. Afterwards, test your concept with users. Remember, this is research, too. Doing so will help you get feedback, verify your assumptions, and collect valuable insights. After this, iterate your concept.

Using concepts to verify your assumptions is key. Small iterative steps involving concept refinement, research, and testing offer a leaner, more realistic approach to UX design.

Act first, research later? Well, not quite. Always be researching. Always be acting.

Don Norman

Good design is invisible

Show the thought and care that go into well-designed products.

 

We try to solve very complicated problems without letting people know how complicated the problem was.
— Jonathan Ive

The effort and thinking that goes into a good design is invisible. While a good design solution might seem obvious, it is not! “I could have thought of that” is common feedback to a well-thought-out design. But the products all around you tell a different story.

Well-designed products are beacons of excellence, yet, they are rare. The not-so-well-designed ones are the norm. The ones that are unhelpful, rude, absent-minded, and unusable. These are the products that surround us.

Well-designed products are silent. They don’t show how much thought was put into them. Nor do they show what it took to get them to this state. Poorly designed products are the opposite. They are obtrusive, and their flaws are obvious and annoying.

Well-designed products seem easy and intuitive. Good design is the absence of noise and friction, allowing for a seamless user experience.

This is reflected in the saying: Design is like air conditioning.” If the air-conditioning is working fine, nobody realizes it’s there, and everyone unconsciously enjoys the experience. But when it is not working, people will realize it fast and will be quite unhappy about it. People will even break a sweat about it.

Designing something simple is hard work; it requires careful thought and attention to detail. This is why you need to explain what went into your design — the thoughts, the concepts, the details, and your knowledge. 

Asking users for advice

Research is not about asking users what they want.

 

If I had asked people what they wanted, they would have said faster horses.

– Henry Ford

This is one of the most cited quotes on innovation and user involvement, associated with Henry Ford. It is often used to dismiss user research – but that is a misunderstanding of its point.

Asking users “why”, and observing how they do things, is essential for user-centered design. Asking users what they want is unhelpful; it’s akin to asking for trouble.

Users are experts on their tasks, workflows, problems, and wishes. This is their area of expertise. They know where things are overly complex for them, where they struggle, where their workflow is broken. And they can even show it to you.

They might have suggestions on how to fix obstacles they encounter, or how to integrate their workarounds into existing solutions. But this feedback is based on their experiences and workflow. They address their own problems, which is fine. It’s not their job to understand or solve the larger issues. That’s your job.

Observing and talking to users helps you find problems and generate solution ideas. However, users can’t tell you what the overall solution should be.

Asking users for their ideal solution can seem like granting them a wish. They might expect it now to be built and be disappointed if it isn’t.

There is value in research – observe users’ behavior to identify their actual needs. Use it to come up with solutions. Ask them what they would like to change, not how. Don’t rely on your users to provide you with a solution.

Translating user feedback into a concept, is your area of expertise, and it’s a job you need to do yourself.

UX Research is no magic 8 ball

Research can only offer insights, not definitive solutions.

There is a common misconception about the role of research in the UX design community. People hope that research (the more the better) will solve their design problem.

However, research doesn’t provide direct answers to design problems, nor does it magically reveal a solution. Instead, research can only provide insights as “food for thought”.

The primary goal of research is to understand users’ mindsets, workflows, and challenges. You want to see what users do, understand why they do it, and get their feedback. These insights are the raw material for your ideation.

However, there’s a limit. At some point, further research won’t bring you closer to an answer. You might think: “I still have so many questions.” — this feeling is normal. Research cannot answer all your questions.

It is your job to collect and combine these insights and use them to come up with a viable solution. This involves analyzing data, brainstorming, formulating assumptions, and creating prototypes. Research cannot replace the ideation process. There will always be ambiguity when coming up with solutions — embrace it.

Research alone won’t hand you an answer on a silver platter. While it lays the groundwork for ideation, you have to come up with solution ideas on your own. To address unanswered questions, turn to ideation to explore possible solutions.

During ideation you will come up with solution ideas. Map them out, brainstorm, document your assumptions, create prototypes, and validate them. This iterative process helps in refining the solution. You need to actively “work towards” the solution.

While research provides the foundation for ideation work, it’s your job to find the right solution. Don’t try to outsource ideation work to research.

The Nabaztag is alive and kicking

  |  |  |  | 

On my birthday in 2009, I bought myself one of the first IoT consumer devices – a cute electronic rabbit, called the Nabaztag.

It was brilliant – it could rotate its ears, read out messages, tell the weather and air quality forecast, play music, “sniff“ and recognize RFID tags, blink lights, and even act on voice commands. I consider the Nabaztag to be the great-grandfather of Alexa and Cortana.

continue >

Convincing the Unconvinced (of the Benefits of UX)

“If you don’t have people that care about usability on your project, your project is doomed.”

— Jeff Atwood

Occasionally you’ll encounter people that question the value of user experience design. My advice is: don’t try to convince them. And don’t be goaded into an ROI (return of investment) discussion of UX with „non-believers“.

Make the case for user experience design and for its contribution once, maybe twice, as people may be unfamiliar with it. But don’t you don’t want a repearing “why this is actually needed?” discussion.

continue >