Most online tutorials explaining how to install Stardew Valley on retro handhelds (like the Anbernic RG35XX-H or RG40XX-H) are outdated. It took me some trial and error to play it on my device. Here is how to get the game files from Steam on your handheld…

Prerequisites

• an retro handheld with Portmaster (e.g., via Knulli CFW)
• an ext4/ formatted SD card for your ROM files
• you bought Stardew Valley on Steam
• you installed the Stardew Valley port via Portmaster on your handheld

continue >

Prototypes make ideas tangible, but explaining the underlying decisions clearly is the tricky part.

Keep your audience in mind. What are their expectations? What do you want them to take away? What should the outcome be?

Provide relevant context, explain design decisions, and point out open questions. 

Start with an overview and mention relevant details later.

Convey your key points. Offer a red thread. Tell a story. 

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.

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.

After a lot of digging I learned that some boards (e.g. RP2040, UNO R4) use the so called Arduino Core API. And this uses non-standard definitions for digitalRead() and pinMode().

Thus, you’ll get errors like this: 

invalid conversion from ‚int‘ to ‚PinStatus‘ 

…when you use these two functions.

This problem is know and discussed in this issue here.

One solution is to block boards that use this API. Works of course, but locks out some users.
Another option (which I chose) is to typecast the pins (see my Hardware.h):

void pinMode(int pin, int mode) {
        ::pinMode(pin, static_cast(mode));    
}    
void digitalWrite(int pin, int value) {
        ::digitalWrite(pin, static_cast(value));    
}

This solves the problem.

I finally took the time to start learning how to write unit tests for Arduino/ESPs.

The first tests I wrote were for the button class. Even though I know in theory how to use it as was as time-consuming to get it started – one reasons why I delayed it quite a bit.

I used AUnit as a framework and the tests run on the devices (for now). I’ll look into abstraction with ExpoyDuino later – first steps first.
Some of my learnings: 

• Memory is an issue on these devices (duh!). Some tests randomly did not work due to memory constraints. Took me a while to figure it out.
• Execution speeds of the devices (ESP8266, ESP32, Uno, Nano) vary significantly. I had to increase buffer times for some devices because they were too fast at executing code, causing debounce times to be triggered.
• After getting accustomed to it, writing the tests became quite fast. I went through the readme and wrote tests based on it.
• A small annoyance – the execution order of tests is based on their name with AUnit – not the order found in code. So, I spent some time renaming groups and tests to have a decent order.

Next, I plan to add unit tests to the other two popular classes, ESPTelnet and ESPRotary.

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.

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

Improve your research by actually doing research.

I’ve seen lots of UX designers unsatisfied with how research is done at their workplace. “We need to become better at research,” they say. They start criticizing the status quo, pointing out shortcomings, and complaining about how things are currently done. They suggest new ways to make research better, and often come up with a new and improved research process to address these flaws. While it’s understandable that UX designers want to improve research quality, it’s usually not wise to start by criticizing. It makes people defensive, not open to new ideas. People are seldom excited about change suggestions or new processes to follow.

The real issue is often not a flawed process, but that there isn’t enough good research or it isn’t used properly. The goal should be to proactively change how research is done by leading by example.

Address the problem of subpar research by doing better research. Make research relevant by showing people that it delivers actionable insights that help them make informed decisions.

Do more relevant research to promote its value. Include people in your research to show them the impact more research can make. Discuss with them what the insight you uncovered might mean. Let them experience the benefits of research firsthand. Make them care. This is how you show the benefits of research.

And keep in mind that the process is just a means to an end. Process change talk is often only procrastination. Instead of wasting time, focus on action.

Complaining is easier than taking action.

Do more joint research to convince people of research.

Show, don’t just tell — actively include others.

Provide value.

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.