Point and click games -The way you interact should make sense.

Most people my age (30s+) that played a lot of games on their PCs, should know about point and click games and their moon logic puzzles. And on top of that, you had those interaction controls that had 3 different action buttons that could be combined in a single one, or had some actions that could have been done in different ways and would in-fact still make sense.

I'm not talking about using a fish that you found at the very start of the game on a robot that is waiting at the very end of the game, or for waiting the guy to go to the toilet and get wrecked by an octopus so that you can get his belt... (If anyone gets the references, you get a high five.)

I'm talking about having a walk command, while the game could simply take use the mouse pointer to where you wanted to walk, and even if you did click on an interactable object, simply walk to the closest point. Or if you had a fridge for example and had an "Open", "Close" and "Interact" commands, the open and close commands (while redundant) could do what they were intended to do, but the "interact" one should work as well; open the door if it's closed, and close it if it's open.

Same with inventory management. In almost all of point and click games you would eventually go to a point where you had to find a couple of objects and combine them to do something else. And in most games I've played of that kind (dare I say all?) the player would have to get both objects and then combine them in the inventory system. Why couldn't I just pick up one part of the object, go close to the second part that could be on a table and then simply "use" the first item directly on the object that is just sitting there? This issue is still present in some form in today's games, latest example I've personally seen being FF14. To give something to an NPC, I had to initiate dialog, and the game would then give me a small on-screen box to place the item in it, either by dragging the item from my inventory to the NPC's inventory, or selecting "give". Why couldn't I just drag the item from my inventory onto the NPC and then program the NPC to simply accept the item and respond with a "Thank you!" kind of a reply? (I'm not talking about point and click games where you have to solve a puzzle by using an item on a character, but on RPG games where characters usually want some items.) Screenspace to world space conversions can be done, so the game can indeed know if you are pointing at something. That's how mouse pointers work in 3D games and applications. (I have to clarify though, that if I remember correctly, I have seen a couple of games that dragging the item from the inventory on the character would give them the item, but as far as i could tell that is still not the norm.)

"You are splitting hairs dude". Well... you may have the best software out there in terms of what it can do, but if it frustrates users with the controls, or your users keep trying to do things differently, then perhaps the controls are not as intuitive as the designer may think and might need tweaking. It's why most 3D programs or photo editing/design packages ended up having similar controls. It goes back to the "you are not your clients" argument. It's only natural that the designer won't have any serious issues with their own interface, but any issues will come up when the client tests it. Case in point, the first pilots that tested the very first F-16 models. Supposedly the new flight system had a control stick that didn't move physically, but instead registered pressure along its axis depending on how the pilot was acting on it. You see the plane was using a cutting edge technology of fly by wire, which means that the pilot didn't actually control the plane's control surfaces but instead was sending information to a computer and the computer was keeping the plane in the air. The issue was that the pilots couldn't tell how much pressure they were exerting on the stick, the engineers at General Dynamics hadn't thought of that or didn't think that it would be an issue. It was the pilots that came back and said that the feeling needs to change as they couldn't tell how much force they were applying, which that would affect their flying. The solution was to add some leeway to the flight stick to move around.

Icon design for application user interface. (Guys the floppy icon should die at last.)

A big part of graphic design - or perhaps the most important part - is to make designs that can pass a message or an information to as many people as possible. It's not just about making pretty pictures. The idea is to try and make any message as universal as possible, though sometimes different cultures, different experiences make that difficult, as the same element in a design may mean different things in different cultures/ people will associate with different things. (With the toilet sign actually being a prime candidate for such a discussion.)

But the damn SAVE icon in a lot of applications isn't one of those special cases! I'm talking to you dear floppy icon. The icon that people born after the 90s knows as the picture to click when they want to save stuff instead of what it actually is, a storage medium. I keep seeing the floppy even in some modern programs. Even the latest version of the Unreal Engine, Microsoft's Visual Studio and Dreamfall Chapters are using the floppy icon even though all of them are distributed electronically (Not criticizing the titles themselves, i actually like all three of them).

"So what's your point?" My point is that the floppy icon is not relevant anymore. And that is a problem when you are not trying to abstract a bit your icons while you are able to do so. What's the purpose of that function? It's not to save a file on a floppy, or on a CD or on a hard drive. It's purpose is to save your work on local storage medium, what ever that medium may be.
Don't use the actual medium as it will eventually be rendered obsolete down the line.
"We'll use a cloud then! People are going crazy about the cloud and using it."
...NO! That is for saving to the cloud, not saving locally. Keep it about the specific function it'll correspond to. Try to abstract the idea. Show that you are putting something into something and try not to take that out of context.

It's about making stuff as future-proof as possible, making them part of concepts instead of binding them to something physical. I still see signs of "no photos allowed" that show a bellows camera... In a time that more people take pictures with the phones instead of even a dSLR camera. Sure a dSLR camera is still relevant and identifiable but for how much longer? And even then, are we going to have a phone on that "no photos" sign? That'll mean "no phones allowed".

It's going to be a hard thing to disassociate the floppy with the meaning of saving, and I'm sentimentally attached to that thing, especially to the mechanical sounds it makes when you insert one. So much in-fact that i still have a drive in my PC even though it's not connected to the motherboard. But seriously; it's time.
Express the function, not the medium. Most mobile operating systems do a good job as they don't have to carry legacy luggage needed for supporting old hardware.

Just a quick, undeveloped idea for "saving",
"loading" and "new file".

Design consistency

Something to take note when designing anything, is consistency. That's because your users or clients will be conditioned/taught and they'll expect something to "be there" or be in a certain way. It's why the close button on Windows hasn't moved from where it is. It may be changing slowly, but it's still there, looking all Xed and red now.

And my issue is with OS X, or rather the way it has implemented a feature in the Finder; to be able to go back to the folder you came from by using the keyboard. You press Command and the UP arrow on the keyboard. From an engineer's point of view it's fine, because the data on a computer are thought as trees. The more folders nested in other folders you open, the deeper down the roots you travel, and so Command + UP to go up, closer to the surface makes sense. But not with the way the GUI is designed.

Look at the buttons right there on the left. They are pointing left and right as if further back the timeline or forward.
Yet with the keyboard you go up and down. You might say that i'm nitpicking and most probably I am, but it actually took some time to get used to it, it's two different ways of thinking and it's nice that it's not the whole OS like that. Command + left arrow or right arrow does the same thing as Shift + <- / -> as far as I know.







In Windows the Windows key with the arrows does something expected, it throws the window in the directions of the arrows. Stacked to the left, to the right, maximised, minimised, similar to what Control+arrows does on OS X.

By keeping things consistent you make for a smoother UI experience, and keep nitpickers happy :).