IT LIVES

Mar. 20th, 2014 10:43 am
jewelfox: A portrait of a foxgryphon with a beak, black fur, magenta hair, fox ears, and a neckband with a large jewel on it. (Default)

I finally completed my “C# for Absolute Beginners” course at the Microsoft Virtual Academy, and just a few lessons in to the Windows Phone for beginners course we’ve managed to successfully create and deploy our first Windows Phone app!

A screenshot of Visual Studio Express 2012 for Windows Phone in debug mode, for an application called 'PetSounds,' with the Windows Phone emulator visible in the foreground. On the emulator's screen is an app called 'MY APPLICATION,' with the words 'Page title' below that, and a single pink button marked 'quack.'
Yes, it's a soundboard with only one sound.

We had to tweak BIOS settings to do this >_o but the course and the one error message we got explained what to do pretty well. And after the work we did for GNOME, where we basically wrote code in Notepad and then ran it in a console window, we feel utterly spoiled by Visual Studio. The debug window and the emulator are cluttering it, here, but it’s actually been really easy to figure out and navigate, and it writes so much of the boilerplate code for us and automatically shows us what our app looks like while we’re working on it.

A screenshot of Visual Studio which looks much less cluttered. On the left-hand side is a pane showing the application's layout, and taking up most of the rest of the screen is a code editor showing the XAML for the layout's markup.
It's so pretty.

Here’s hoping we’ll have more to show you all soon!

jewelfox: A portrait of a foxgryphon with a beak, black fur, magenta hair, fox ears, and a neckband with a large jewel on it. (Default)
GNOME 3 introduced what I think is a really cool concept: The global application menu.



As you can see, it's clean and modern, and reminiscent of Android's menu button. It just has a ton of problems right now.
  1. It's not discoverable. It looks like a Windows XP style taskbar entry. Those only have the option to close the window or perform window functions like maximizing. And sure enough, "Quit" is the only option available in most apps which run on GNOME, or even on earlier versions of core GNOME apps.

  2. It's not complete. Core GNOME apps like Totem and Web have so many menu options that they don't all fit in the "app menu." Because of this, they use either a classic Windows-style menu bar or a "Chrome wrench" style menu button (which is now a core GTK+ widget).



  3. It's inconsistent. I'm not aware of any design document explaining when to use what, and my understanding of how it works keeps getting broken. For instance, I'm used to the app menu replacing a Windows-style menu bar, so when I saw that Totem had the latter I ended up driving myself to frustration trying to find its Preferences dialog, before clicking on the app menu and finding it there.
The only guideline I'm aware of is that in multi-window apps, the app menu is supposed to apply to all of them, while the Chrome-style menu button is supposed to be for the one window. But I only heard that second-hand.

Where and when did we explain our design decisions to GNOME users and developers? How many of them are aware?

Un-breaking the app menu

Here's my proposal for how to make it work, based on the expectations I formed while using and developing with it.
  1. Explain the app menu to users. Every modern OS has a friendly introduction which explains the most basic, non-obvious concepts. For GNOME, this could be as simple as a single-screen "Welcome to GNOME" app, which helpfully points out the Activities screen, notification bar, and app menu.

  2. The app menu has the most basic options. An app always has one, and it always has the core, global functions in it: "About," "Preferences," and "Quit."

  3. Other menus have All The Options. People who are used to them expect that a Windows-style menu bar, or a Chrome wrench style menu button, will have a complete listing of the app's functionality. If an app has either of these (and modern GNOME apps should prefer the GTK+ menu button to space-eating Windows-style menus), it will contain all of that app's options, including the ones in the app menu. This makes GNOME more accessible and less frustrating.
But why have an app menu at all, then? Because it's a better way of doing things. It's simpler for users and developers, it's much more attractive and elegant, it's easy to remember once you've been shown, and it echoes the functionality of a modern OS (Android) in much the same way that GNOME's legacy menus mimic those of a legacy OS (pre-Windows 8).

Plus, it makes the apps themselves look much cleaner and take up less room on small screens.

Ideally, the App Menu will contain all of a given app's functionality. This is the assumption new GNOME apps (like Documents) are building on, and the one certain existing apps (like Empathy) are adopting.

The App Menu is the future that we are transitioning towards. Let's make it as painless as possible for users and developers, by adopting guidelines that get rid of frustration.

About us

~ Fox | Gem | Rei ~

We tell stories, paint minis, collect identity words, and share them all with our readers. If something we write helps you, let us know.

~ She / her ~

Subscribe

RSS Atom

Tags

Style Credit

Page generated Apr. 28th, 2017 05:56 pm
Powered by Dreamwidth Studios