I have to port a GUI that is currently running on a pc, to a wince device. I have already compiled the code on a win CE platform, the problem is now with the size of the screen of the device which is smaller than some of the dialog boxes of the GUI. I could resize some them in resource view of visual studio 2005. I am unable to proceed further as a lot of screens have bitmaps mapped to them and i cannot just resize the dialog boxes without changing the corresponding bitmaps.
What is the best way to proceed- my last resort would be to disable the bitmaps and redraw them at a later stage.
is there some method of automatically mapping the size of the screen to all the dialog boxes so that they would automatically resize (alongwith the assocaiated buttons etc)
Honestly I think my advise would be to stop and think about the differences between the two contexts before event considering how you would scale the interfaces.
PCs and phones have completely different interaction paradigms and simply scaling from a PC to a phone is very unlikely to work. Even if you could, it's likely to produce an unsatisfactory user experience.
I would expect that the best way to proceed is to sit down and draft up a new UI for the phones. Then bring you back ground code across from the PC and code up the interface part to work with the new UI. If you code is designed according to MVC principles then you are just looking at recoding the controllers and redesigning the views.
Related
On the iPhone, we design applications around a standard screen size of 320x480. Is there a standard screen size we should use for developing Mac applications, specifically ones targeted to the Mac App Store?
You don't. Desktop computers don't have a fixed size like phones do. Users could have a screen (or two or six) with a resolution anywhere from 800x600 to 3200x2400 or more.
Instead, design your application to be dynamically resizable. Allow the user to resize windows by dragging their corners to make them as large as they want. Ensure that the layout of elements is fluid, and that they move/resize accordingly as their parent window is resized.
Whatever you do, do not try and lock your users into a particular resolution or window size. They will resent it, and your app will not be very successful. You need to abandon the iPhone model when developing Macintosh applications. There are some similarities, but also lots of important differences.
Examine the other applications on your computer, and see how they behave. Good examples are the applications Apple bundles with new Macs, like iTunes, iPhoto, TextEdit, Pages, and Keynote, among others. Certain third-party companies also design award-winning software applications, like Panic's Coda, Fetch, and even Microsoft Office. Hard to go wrong by following their example.
For all modern macs, at least 1024x768 will be usable screen real estate (the actual screen will be larger, but you need to account for menu bars, 16:9, etc.). Still, this is generally not a good question to ask - you should probably have dialogs that look good at 800x600 and scale larger at the very least - most people like to be able to arrange their windows to their preferences, and if you have a large minimum size that will be very annoying.
I am debating whether to hide or not to hide the system tray in a Windows Phone 7 application. I've not found any general suggestions on this issue -the official Windows Phone design guidelines don't address this issue at all - except for Jeff Wilcox's blog post who suggested that he personally likes to see the system tray in applications. I'd like some general advice on this issue from other Windows Phone developers.
Some reasons for showing the system tray are
Doesn't take up that much space
Users may want to see it at times
Reasons for hiding it are
You can't control its background: unless you're using PhoneBackgroundBrush as the background the top row will stand out
Lots of widely used / official apps already hide it: all games as well as the official Facebook and Twitter app.
I'd appreciate all advice on this.
Transparency and colors are now possible with Mango by setting its BackgroundColor and Opacity :
shell:SystemTray.IsVisible="True"
shell:SystemTray.BackgroundColor="Transparent"
shell:SystemTray.Opacity="0"
I would say by default show it unless it really gets in the way in a way you can't workaround, especially if its an app and not a game.
I would say it depends on the application/game you are writing
If the app needs a network connection or if you will be in the application for a long period of time show it so the user can keep an eye on network and battery.
If you need the extra screen space (for a game?), and you rarely need network hide it.
Or... I guess you leave it up-to the user and give them a setting to programatically hide/show it.
I think its best to use the tray in applications that are tools or utilities. Typically these users would prefer more info than less when they're using applications on the phone (battery, network, time).
Also adding the tray in there tends to make the application look more native on the phone (according to me and others I've asked), which is a big plus because the user associates your app as if it was built with the phone OS.
But if the application is a game, media, etc. type of application I recommend you take it off, especially on panorama because it takes away from the intended design. Also these types of applications focus on the content and seeing multiple little icons at the top can take away from the experience.
Really to me the space it occupies isn't really THAT much, so that shouldn't be too much of an issue. But rather the purpose of the app as stated above.
I do like the suggestions that have been given as far as giving the user the choice. Check out this code:
bool ShowTray;
//ASK USER WHAT THEY WANT
//ShowTray = true or false;
SystemTray.IsVisible = ShowTray;
I've been reluctantly hiding, at least on any view where I have a background image; otherwise it looks too strange to me. I've been considering a setting in my app that would allow the user to choose, and persisting that to isolated storage.
Also considering maybe having the top of the screen in phone background brush color and have it fade / blend into another color or background image. Not sure how well that would turn out but as long as it is not a cheesy looking gradient effect, perhaps.
I'm hoping eventually MS will soon add support for transparency in the system tray or otherwise help address this issue. As a user I wish that I could force the system tray to always be visible across all apps, but as a developer I realize that the visual effect often doesn't look good.
Perhaps if the community came up with a new UX metaphor where maybe double-tapping in the system tray area would toggle whether it is visible. A single tap could perhaps start to animate / pop / hint at the system tray...
Assume a GUI application is opened on three machines running Windows XP, Windows Vista and Windows7. In all the three machines, the screen resolution and the DPI settings are set to be the same value. Will there be a difference in the way the application is displayed on the screen in terms of number of pixels used and their position on the screen?
The reason for asking this question is:
I am using position based record-and-play method for GUI automation. Any change in the position of a control can impact the playback of the GUI recording. I want to be sure that a recording captured on Windowx XP platform works on Vista and Windows7 platforms.
Yes. The OS chrome (starting with window borders and titles) have different styles (e.g. Vista and Win7 will likely have Aero on and thus translucent title).
And that's before considering any OS dependent code in the application.
The menu bars will probably all be different sizes, so you'll probably need to record separately on all three machines.
Bearing in mind, that each user could have any number of accessibility settings on/off, any DPI setting, and also that features such as button sizes and window border sizes are different on each of these OS's...
No one here could possibly guarantee you'll be fine - the only way is to test.
A side note: there MUST be a better way than position based playback? I've used tools previously that can read screen text and base the automated navigation on that, which seems far more sensible, but still horribly flawed.
Through experience I have found that the native windows forms/components don’t like to be changed. I know using Delphi or Visual Studio you are given native windows components to populate a form or window with and then you attach code on events that these components may do (onClick for example).
However, how do all of these programs like Word or google’s Chrome browser alter the standard windows’ window? I thought it was somehow protected?
Chrome seems to have tabs actually on the window’s frame?
I know you can also get toolkits like Swing and QT that have their own controls/components to populate a form. How do these work? (How does the operating system/computer know what a non-native button should act like? For example; Chrome's back and forward buttons, they're not native components?).
I can understand how OpenGL/DirectX window would work because you’re telling the computer exactly what to draw with polygons/quads.
I hope this question is clear!
Windows does not protect GUI elements. Windows and controls can be subclassed to handle various drawing operations in a custom way. For example, windows may override and reimplement the handling of the WM_NCPAINT message to draw a custom titlebar and frame:
http://msdn.microsoft.com/en-us/library/dd145212(VS.85).aspx
Some Windows controls have an "owner-draw" mode. If you use this, you get to draw the control (or at least vital parts of the control), while Windows takes care of responding to user input in the standard way.
Swing ant QT draw their own widgets at a low level using basic primitives, but they also have theme engines which can mimic the native controls.
Qt moved to native controls a while back. As for how swing does it, it gets a basic window from the OS. Then much like Opengl\Directx it does all of the drawing with in that window. As for where to position things that is what the layout managers do. Each manager has a layout style horizontal, vertical, grid, components it has to draw and a section of window it is expected to fill. From there it does some pretty easy math to allocate its space to its controls.
There's no magic: non native controls are simply drawn on a blank window. Or, instead of being drawn they may be represented as one of several bitmaps based on state (ie: a button may be represented as a .png for the normal state, another .png for the pressed state, etc)
Up to now I been using the pda emulator in visual studios 2008 (I am using windows mobile 6.1 professional sdk).
So I just dragged and dropped most of my GUI components into the form. In one instance I made a panel then in this panel I dynamically generated labels in it with certain location positions.
I then put it on my Hp PAQ 110 Classic pda and it looked fine and everything. Then I was looking through the emulators one of them was called professional square. So I decided to run it and when it ran my program it looked like crap.
I had missing labels, missing controls and it just looked horrible.
I thought maybe it would like do some resizing for me but it seems to either did a shitty job or it does not do it at all.
So how do you make a GUI that will work well on all mobile phones(or at least the vast majority of them).
Is there like X number of types of mobile phones? Like the emulator emulates a pda and it works on my HP one so I am assuming that all window mobile device pdas have the same screen size.
Then the next question is how do you make the controls position properly from one device to another? I heard of people using XML files that have all the location position, sizes and etc that they call up and I guess essentially generate the GUI dynamically based on the information in XML.
But I could not find any examples how the XML file would look like, how to detect what phone type it is so that I could call up the right node of the file for that phone.
I am not sure if there are any other ways but this seems better then a set of GUI forms for each one.
Also would it be recommended to have most things in a panel so that way even if the stuff is bigger you can at least turn auto scrolling on.
thanks
I spent a good amount of time looking at different solutions for this problem (see my question here as well) and ended up with a pragmatic approach - consistent use of docking. You have to restrict yourself to the least common denominator, i.e. the lowest resolution you want to support, in terms of how much you can fit on the screen. The good news was that grids always use the entire available real estate, and my forms flow correctly on all devices and the screens don't look like they are broken.
This is far from being an easy task. You can follow some guidelines, but the only thing that will actually work is to always test the User Interface in all possible screen resolutions. Emulators are a good way to start, however it will be better to have an actual device. Some things like font sizes and text readability can only be tested in a real device. So, these are my advices:
Try to use docking for positioning your controls.
You need to be able to handle orientation changes correctly. Using docking helps, but again you always need to test in different screen resolutions.
At some point you will find out that it is inevitable to detect the screen size and adapt the User Interface dynamically. I don't agree that you should restrict yourself to only display what can fit in the smallest screen. A professional application should adapt itself to the available screen size and take full advantage of it.
Structure your application so that it is easy to support new screen resolutions. Make the main User Interface code screen size agnostic. Make it get all information about dynamic resizing - positioning from a configuration class. This way you only need to enhance a single item in your code in order to support a new screen resolution.
And of course:
Test in all possible screen resolutions. After even a minor change to the User Interface, retest.
Eventhough the above posts where helpful this video I found solves all my problems and you don't have to develop for the the lowest screen.
http://www.microsoft.com/events/series/detail/webcastdetails.aspx?seriesid=86&webcastid=5112