We are implementing a Windows 7 application that displays a pop-up in the taskbar's notification area.
There are two version of the simple form.
and the compact version:
Which one is closer to Windows's UI guidelines? Is there a good reason to prefer one over the other?
The second one looks better to me. It's hard to put my finger on the exact difference between them, but it looks like there's more horizontal padding between the borders on the first one.
That's not consistent with the standard UI or the sample pictures in Microsoft's handy UI documentation/guidebook.
For example, there's very little horizontal (or vertical) padding in these two notification area pop-ups:
The standard border padding for windows (according to Microsoft's UX guidelines) is 7 DLUs (about 12 pixels) all the way around. When in doubt, I suggest using that.
Beyond the UI/UX guidelines, it's also important to consider functionality. A pop-up window should not take up the entire screen, so using space as parsimoniously as possible is always a good idea. Since the extra padding doesn't really add anything to or make your dialog more usable, it's superfluous.
Related
I am trying to get the width and height of all the windows. I did this easily with GetWindowRect however the styling in Win8.1+ seems such that there is a border on some windows and thats not being included. When I move/drag the window, this area moves with the window, so I expected it would be apart of its geometry. Is this known? Is there away to include the border width?
New Example
I created a second screenshot to explain after I see some confusion in the comments.
I have two windows side by side as seen in this image here:
Now if I take the GetWindowRect of the left and right windows, it should be a continuous rectangle around both of thse windows. However in the below we see this is not the case. I put a black fade over the whole desktop and cut out just the parts of the GetWindowRect for each window, we see the left window GetWindowRect is a bit smaller, this is my problem.
Old Example
For example this is a screenshot, using the cleared/non-black curtain area is what GetWindowRect identified as the width height, x and y:
We see there is some area of the window not included, I think this is the border? I used photoshop here to put a blue border around what all should have been:
And just for clarity I put an inner red border to show that the area between the red and blue borders was what should have been included, but was not:
Does anyone know how to include this "border" in the GetWindowRect?
Yes, GetWindowRect() lies to you. As you found out. It is a necessary lie. Goes back to Vista, the first Windows version that gave resizable windows their fat border. A pretty necessary feature, high screen resolutions were getting pretty common and the traditional 2-pixel border was getting too hard to hit with a mouse.
That created a massive compatibility problem however, many programs that create a window use CreateWindowEx(), you specify the outer window size. And don't use AdjustWindowRectEx(), the function that you must use to calculate the window size you need. Necessary because almost every window actually cares about the client size of the window. The part you fill with content. If they would have done nothing then legacy programs would end up creating windows with a client area that is too small, no longer fitting the content or aligning it out of whack. Very, very ugly.
So GetWindowRect() lies and pretends that the window has the traditional 2-pixel border. Pretty consistent lie, if you ask for the border size with GetSystemMetrics() then you get 2 back, even though it is 5. All works pretty well, until you start caring about positioning windows next to each other. Impossible to lie about that.
Turning off the lies requires letting Windows know that you are aware of the consequences of the fat borders. And know how to deal with Aero being turned off, possible on Vista and Win7. You must select the sub-system version number in the EXE file header and pick at least 6.00. The vast majority of programs use the legacy value, 4.00. Exactly how that's done depends on your tooling, for the Microsoft linker it is the /SUBSYSTEM option. It can be changed after the program was built with Editbin.exe, /SUBSYSTEM option. The program will no longer run on XP and earlier.
Windows 10 took an interesting new approach to this problem. The skinny borders are back. But now with a much bigger drop-shadow, the mouse is active beyond the border, even for windows that don't have a shadow. Works pretty well, hopefully we can all forget about this appcompat detail soon :)
I am fairly new to Mac and iOS programming, and have recently decided to get really serious about developing applications for both platforms. The first step I took was to register to the Mac and iOS developer programs, download Xcode and study a book about Objective-C. I spent the last 6 weeks familiarizing myself with Objective-C, its syntax, concepts and the Foundation framework, and was purely developing command line applications for those purposes.
Now, the next step seems to be Cocoa and developing applications that offer graphical UIs, which I'm now looking into. Now, here's an issue I am having with this: as I am completely blind, I cannot visually see the screen. Thus, I use VoiceOver, the screen reader built into OS X and iOS. Maybe some of you devs have heard of VoiceOver at some point, as Apple has specified a variety of accessibility guidelines that concern VoiceOver. On that note, thanks a lot to all of you who abide by those guidelines, your effort is greatly appreciated!!! :-)
As for Xcode, it actually works really well with VoiceOver (VO). Adding in new UI elements is also no big deal, I can just copy them from the library and paste them into the view. However, I cannot drag them around and set them up in an appealing fashion, or at least I haven't found any way of doing it just yet as I'm just starting out!
Now, I really would like to know if there is any 'textual' way of arranging UI elements. I know the inspector has a great variety of options, but I'm not sure yet if any of them would let me, say, change the coordinates of an UI element by hand. Also, I've read about the new constraints which help create a consistent layout, but at this point I'm not really familiar with how they can be used or if they would be at all helpful in my case.
Also, I do realize that producing an interface that is 100% appealing to a sighted end user may not be possible for me, as it's hard for me to decide on color selections or to design a logo. Thus, I would probably need to hire someone for those things. However, if it would be possible for me to just specify the layout roughly, that would already help me a lot!
Thanks for any ideas / suggestions :-)
Robin
I'm not a blind user myself but I've worked with VoiceOver so hopefully some of this will help. I'm making this a community answer so feel free to add tips from your own experience if you've worked with UI layout in Xcode with VoiceOver.
When editing UI in Xcode there is an Inspector where you can change the size and position of the views. The shortcut to get to the Size Inspector is Alt+Command+5. The same shortcut works with VoiceOver.
You said that you were coding for both iOS and OS X. On iOS the y-axis starts in the top and points downward (so a higher y value means that the view is lower on the screen). This means that x and y specify the upper left corner of the view and the width and height extends to the right and down from there.
On OS X it's the opposite. The y-axis start at the bottom and a higher y value means that the view is higher on the screen. In both cases the x-axis goes from left to right. This means that x and y specifies the lower left corner and the width and height extends to the right an up.
Further, each view is positioned relative to their parent instead of absolute coordinates. This means that if you position a view at x=10 and y=30 and then position another view inside that at x=5 and y=10 it will have an absolute position on the screen that is x=15 and y=40.
If you can picture the layout in your head then you should be able to do it like this but it may still be hard to do.
Update
At the top of the hierarchy these coordinates relate to the size of the window. On iOS you have fixed sizes (320×480 for the iPhone and 1024×768 for the iPad). Depending on if the device is in landscape or portrait one of these is the width and the other is the heigh. You usually subtract 20 pixels from the height to account for the status bar. So the coordinate where y=0 would be directly below the status bar.
On OS X you can change the size of the window yourself. I will try and explain where to find it.
At the top level. Navigate to the "source code group" and interact with it. There you should find a "navigation bar group" and a "table" and a "scroll area". Interact with the table. In that table you should find a list of Placeholders and a list of Objects. One of the Objects will be the "Window". With the Window selected, all the inspectors will change properties of the Window. You can quickly jump to the Size Inspector by changing to any inspector and then back to the Size Inspector. For exaple type Alt+Command+4 and then Alt+Command+5. The first two elements in the Size Inspector should be the Width and Height of the Window.
This discussion will inevitably go off-topic, but here are my ideas:
Consider specializing in something else. There are so many things a programmer can work on. Many, if not most, programmers can enjoy long, successful careers without ever having to arrange any UI elements. Frankly, I don't think that this is particularly exciting, unless you have more of a designer mindset.
Alternatively, whatever tool you are using to arrange the elements, this layout is probably saved to some file, probably in some XML-like fashion. Find this file and edit it.
If you want to get really good at arranging UI elements, consider first hiring several people to do multiple arrangements for you. Then analyze the numbers and come up with some kind of formula that will be a good heuristic for such an arrangement. Or perhaps somebody has already come up with this kind of formula.
I like Windows Phone 7's interface experience. I find it very innovative compared to other interfaces (be it mobile, desktop or web). Yet it's still no less usable. All in all a very good shift from the usual in the right direction.
Some of the effects could be used in web interfaces to enhance the experience without sacrificing usability and intuitiveness.
Effects I'm talking about:
perspective animation when you click on a particular hub on the home screen)
elements executing animation in different times (hub being clicked moves last)
horizontal slide with different slide amounts (titles and background images move less than screen width which gives it a feeling of depth dimension)
etc.
2 questions
Do you know of any public website that uses at least one of the aforementioned effects and does that without the use of plugins (like Flash or Silverlight)?
Is there any JavaScript library that would provide such effects (at least the different delay and different amount sliding technique)?
Extremely simplified example
I've taken some time to put up a simplified example of transition effect that could be adopted on mobile devices and simulates at least a bit of the fine Windows Phone 7.x transitions.
Just click on any tile and see others zoom out and slide to left.
Let me know what you think about this example.
Something came out just these days
Take a look at this HTML demo written by Microsoft (or one of its partners). Blew my mind away as being the closest to WP7 experience! Amazing!
The delay and sliding should be easily handled by jQuery, but I am not aware of someone who has alredy bundled up something to directly emulate the WP7 interface. Sounds like a fun project.
For example: I would like to know exactly what system metrics to use to know how wide the borders of a window are going to be. With a given set of visual styles, what borders will appear, and how wide will they be (what system metrics can be queried to know exactly and correctly how wide they'll be)?
Similarly, for a button, how wide are its borders in various states? Using different themes? What system metrics or theme functions can give me a absolutely correct answer on how wide, how tall, how many, what offsets?
Generally speaking, my custom interface code usually contains things like:
myrect.Offset(4,4); // empirical evidence indicates it's actually 4 more pixels per side that Windows adds in but doesn't tell me about...
I hate code like this - littered with magical numbers that may change depending on version of Windows, whether Aero is enabled or not, whether the customer is running this theme or that theme, or using large font / high DPI mode, or not, etc.
But I haven't, in my 15+ years of Windows GUI programming, ever seen a really good white paper or diagram or chart that describes the actual composition of all std. windows controls, and where their various visual parts' metrics come from.
Is anyone out there aware of a resource even similar to this? A white paper? A diagram? A detailed blog discussion? Anything?
Thanks for any help you may have!
EDIT: the GUI guidelines idea doesn't actually describe the internal composition of the controls visual parts - just their overall size and spacing between controls.
I really would love to have something that describes in excruciating detail the border sizes, offsets, and what system metrics control each of these things.
What about the Windows User Experience Interaction Guidelines? [Document Index] [PDF download]
It includes diagrams like this:
This is not a complete answer to your question, though, because it only tells you how the controls are supposed to be laid out, not how they actually are. And it doesn’t address what happens under different themes.
I m, on a daily basis creating web pages. My preferred development screen resolution is: 1600x1200 but what is yours?
And do you use any other plug-ins?
I use window re sizer 1.0 for Firefox. But are there better options?
In my opinion, if you're using a window resizer, you're already on top of the game. I try to aim for pages that work well on a 1024x768 screen, accounting for scrollbars and toolbars and whatnot. It may be worth resizing your screen to 1024x768 (or whatever the minimum is that you support) every once in a while just to fully understand that user experience, but in general the window resizer keeps you aware enough.
I disagree - fixed size layouts are just fine. In fact, Stackoverflow.com uses a fixed size layout, as do a great many professional sites out there. The reason? Predictability.
A few things:
Never have horizontal scroll bars
Try to avoid vertical scroll bars when it's reasonable to do so
Remember, AJAX and other newer technologies can help you save space on your page with popups and other niceties.
My 2 cents,
-Doug
It shouldn't matter - design your web pages to be flexible and fluid such that they degrade gracefully on any reasonable screen resolution. Cater for mobile devices with very minimal screen space and massive displays.
I develop with a 2x1440x900 setup, but I leave Firefox as a window at 1024x768 using Web Developer Toolbar.
The dual monitor setup is really useful when you have the code on one screen and Firefox on the other.
I wouldn't go over 800x600. However, ideally your layout is not fixed to a screen size, and can resize and still look right.
I stick with 1024x768. It's usually big enough for what you need to display, and not everyone is quite to 1600x1200 yet. Maybe in a few years. I'd stick with a smaller display...that way it may force you to be more design conscience.
Two screens are invaluable regardless of screen size. One screen to run your editor, and one screen to run your browser. It's amazing how much smoother development becomes.
With my stats showing 1024x768 as my users' dominant resolution, I certainly wouldn't go below that. Beyond that, I agree with, apparently, everyone else here that fixed size layouts are just a bad idea, and your design should adapt to render context.
For the love of Pete don't use pixel sized fonts. Use em or pt sizing instead.
It all really depends on what kind of page you are designing. I would try to design with the ability for the page to scale in mind. There is nothing I hate more than having to zoom in a page that was designed for 800x600 on a 1920x1200 display.
I think the best advice given here is just to try it at different resolutions instead of your native one, and try to make it look good at a variety of sizes.