The long road to changes in the graphical user interface


There are times when I wonder whether I should try to tackle some issue related to the graphical user interface in Button Men. And then I wonder whether I shouldn't leave the issue to someone more capable.

I am the first to admit that I have no real tendency towards graphic design, and I'm not awfully good at Javascript or CSS. However, I can usually muddle my way through to implement something that works and can be unit tested.

My real dilemma, though, is that that testers often disagree strongly with me on what they consider to be important. My overriding concern is to get things done so that they are functional. I lose interest when people get hung up on issues of consistency, aesthetics, or emotional response. I've always felt that it was more important to make a new feature available for use as soon as possible, even if it still had some rough edges, than to delay it until it was implemented perfectly.

The issue is not only related to me, though. Many pull requests for changing the graphical user interface that were not authored by me have engendered lengthy and sometimes heated discussion. It seems that the user interface is one of those things where everyone seems to hold a strong opinion, and inertia is difficult to overcome.

This tension between speed of implementation and aesthetic acceptability is one that we wrestle with often, and in my opinion, we weight aesthetic acceptability too highly at the moment. As a consequence, I feel that pull requests including changes to the graphical user interface stay open longer than is really necessary, which can be both frustrating and demotivational.

Maybe we can find a way to provisionally accept a feature based on its functionality, with the proviso that the aesthetics may need to be tweaked over time.

Maybe we'll be able to find another process to implement changes to the graphical user interface that can shorten the road to deployment.

And maybe someone will remind me that my blue-sky thinking needs to change because I have forgotten something important.

Comments

Post a Comment

Popular posts from this blog

The thorny interaction between konstant and fire

Those who have been on the site for a while will know that there are quite a few buttons that are not yet playable. Mostly, this is because a die or button skill hasn't yet been implemented. But sometimes, the reasons are more subtle. Two of the US States buttons, Arizona [k(7) g(9) (12) F(15) (X)] and Hawaii [n(4) m(5) k(8) F(13) d(Y)] have been disabled for the entirety of the time that most of the other US States buttons have been playable, since January 2016. And on a first glance, it would appear that these buttons should have been enabled for play, since all the component die skills were already implemented at the time. The story really starts in September 2015, when devious and irilyth found a konstant bug while testing the button Hawaii on the dev testing site. It turned out to be caused by the underlying code not correctly determining whether an attack involving konstant requires fire support. I submitted a fix for this, and as usual, Chaos ran her automated testing bot o...
Read more

Phases of a turn

One of the first times I really thought about game states in a game was when I was learning Magic: the Gathering. There, it can be really important to know which phase of the turn is currently occurring, so much so that sometimes, you need to explicitly say things like "I'm beginning my upkeep phase" or "I'm about to end my main phase", so that opponents were given the opportunity to react during that phase. When I started working on Button Men, I thought that things would be much simpler, and that turn order wouldn't be nearly as important. Looking at the status of class BMGameState in July 2013, many of the game states were already present: startGame applyHandicaps chooseAuxiliaryDice loadDiceIntoButtons addAvailableDiceToGame specifyDice determineInitiative startRound startTurn endTurn endRound endGame Interestingly, we haven't yet used the game state set aside for allowing a handicapped game, it's just there as a placeholde...
Read more

Why PHP? A brief history of the resurrection of Button Men Online

For anyone who knows anything about web development, it may seem odd that we are using PHP for our back-end, especially since we made the decision in 2012, when there were many other feasible languages available. Here is the story of how we started out, and how we incidentally ended up being stuck with PHP. 12 Nov 2012 I broached the subject of resurrecting the Button Men Online site on the  Buttonmen Site Outage News  group, after nine months of downtime of the old site. One of the things that I left open was the choice of programming languages. 13 Nov 2012 After getting a bit of interest, I posted a suggestion on November 13 that we go with Python and PostgreSQL. Brooks chimes in that he is a Zend certified PHP developer, and suggests that Python frameworks may not be as robust as the Apache backend, and that the Apache backend is more widely supported on cloud architecture. He also mentions Pagodabox, which he uses for his PHP projects. Chaos posts that she knows Pyt...
Read more