I just bought this model and it has various poses available in the outliner. How can I use them? I imagine they are some kind of controllers. Any help is appreciated.
Visibility: On/Off, activate them and deactivate the old one
Related
Im doing a paper for my college and I need some help finding some documentation or sources on some types of UI.
The types I need to research are WWWUI, MUI and VRUI. I know they are actually GUI but with added functionality of some sort.
I need to implement a check box which can have multiple states, I am new to Xamarin and OSX development. I could not find any built in control that I could use. I guess I need to implement a custom user control, which class should I derive from and how should I approach it?
I don't know if you checked this already, but this might help you :
https://developer.xamarin.com/guides/mac/user-interface/custom-controls/
It's not much as help but it might lead you to something. Hope it will help you at least a little bit. It helped me to start with custom controls as I am in about the same situation as yours, but with different kind of controls needed
We are building an companion presentation that will be displayed on computer screens next to a museum exhibit. I believe the machines are going to be running OSX (no touchscreens) and the users will need a mouse at minimum.
Does anyone have an recommendations for what environment to build in (flash, air, web, cocoa, etc) that will allow us to restrict access to the computer itself? Our main concern is with people alt-tabbing, command-q'ing, command-option-escape'ing, etc etc etc. Anything that will let them exit the presentation and access the main system is a major issue.
Thanks.
OS X has support for various kiosk modes which you can trigger from pretty much any programming environment. Something Web-based seems like a good strategy since it doesn't limit you much. Opera has kiosk support (which I haven't used) as does iCab. There are also some purpose-designed kiosk browsers such as Plainview and wKiosk.
I think what you are looking for is called "Kiosk mode":
http://www.mactech.com/articles/mactech/Vol.19/19.12/KioskModeFeatures/index.html
Also, I would avoid giving the users a mouse. Mice will get destroyed in such exhibits over time. A better option might be a touchpad. I don't know for sure, but I would imagine they will have a longer lifespan in a display. I know trackballs used to be very popular for kiosks but the ones I've seen look like specially purchased devices, not the standard Kensington ones you get at the shop around the corner...
For common elements, such as a logout button on a website, save button in an application, need to be presented to users in an standard, easily discoverable way. How do you go about deciding where in your application to place these elements? Do you research similar apps and try to follow convention? Is there any database that attempts to track the use of these common elements or is this too hard to capture?
The goal is to put UI elements where users expect to find them. You want to leverage the knowledge that they already have about how applications work.
So, looking at the the UI elements for the OS that you are targeting is helpful. Unfortunately, there are some key differences here between Windows and Mac, you will have to pick one or switch based on the OS if you target both.
Looking at applications that are similar to yours is generally not a good idea unless you believe that people using your product are already using these other products and you want them to switch.
Instead, you look at products that are complementary to yours, or products that you expect everyone is familiar with. At one point it was a good idea to look at Excel and Word to know how an Windows application should work; But I don't think that the current versions of Excel and Word are a good model, they deviate too much from the way the OS works. You could still use older versions - before the ribbon, if you are targeting Windows.
It's best to be a bit conservative, choosing applications that have been out for a while and people are likely to be comfortable with rather than chasing the latest design innovations that are coming out of Apple and Microsoft.
I research similar apps and try to follow convention...
E.g. logout goes up in the top right near the "X"/close in most applications
Save/Edit buttons towards the bottom of the thing I'm editing... since contextually they happen after I finish the editing I just did.
Then again, you have apps like Outlook... that have the send/save buttons at the top.
In general though... I have application-wide actions (e.g. login/logout/help user info at the top)
Item specific tend to be inline or just after the item they are adding/editing.
I totally agree with leveraging knowledge that the user already has. Every techie is (or probably is) familiar with http://www.dice.com. It frustrates me to no end to see that their website is designed with the logout "link" (not even a "button") at the very BOTTOM of the page. In this age of security conciousness, what a place to put a logout link ???
I have used DeLorme Street Atlas USA mapping software ever since Windows 3.1. About five or so years ago, they changed their entire user interface, moving AWAY from all of the features that make application software in the Windows environment easy to learn and navigate and SIMILAR from one application to another, and TO a totally foreign user interface, unique to their individual product offering.
Was it necessary ? probably not... What was it's impact to the current user community ? probably not thought about... What was it's impact to someone new to Street Atlas USA ?? Probably LESSENED the adoption rate of the software product, because it looked so foreign compared to a user's already-used applications developed with the common Windows-based look and feel.
Although books can be written on how "we" dislike Microsoft, the value-added benefit to Windows since it's infancy with Windows 3.1 was that you could create totally different software applications, but have a SIMILAR navigation style threaded throughout all of the applications, LESSENING the new application learning curve, and INCREASING the adoption rate amongst software applications for the Windows user.
Leveraging positive current user knowledge can only increase the adoption rate of a software product. Why re-invent the wheel, when the current wheel is known and adequate ?
I've done plenty of programming before for CLI and the web, however recently I am getting into desktop GUI programming.
Most of the tutorials for GUI programming I found just explain the different controls you can use and leave it at that. Some of the better ones also skim over a few usability issues.
However, my problem is not with the APIs, or the theory but with my code.
How are you supposed to organise different views your application might have (e.g. a IM application has a login view, a contacts list view, a conversation view etc.).
Are these supposed to be different classes or different methods on one class?
Different panels that are hidden and revealed, or different windows altogether?
I'm hoping for answers as language agnostic as possible, but in case that's not possible, the languages/frameworks I am considering are Java/Swing or C#/WPF. However, if there's another language/framework that is significantly better for learning from, I would consider using that.
Normally each view will be a seperate class in a seperate file. The class will then most likely implement some base class like Window or Control.
As far as organization, if it's a simple app, put them in the root or in a UI folder. Or perhaps a Window folder and Controls folder.
If it's a large app with several views, than break them out into functionality, i.e. an IM folder.
I would say go with what Joshua said and as far as using different panels that are hidden and revealed, i've worked on old code and it's a nightmare to re-use (8000+ lines of Delphi 6!) so stick with different windows as much as possible!
The generally recommended overall structure of the program is the model-view-controller (MVC) type of structure. So, first off, don't make the actual data part of the views, it goes into the model. From here, since the only data in each view window is now almost entirely just layout information and what to do on an action (click, data display, etc), if these are different, they should probably be different classes. If there's some general functionality that can be factored out, you can make this a base class and inherit from it, but in the end, windows with different functionalities should be different classes.
If you are going to be using one of the mainstream IDEs it will handle some of this work for you. The default will be a different class for each form. Hidden panels and tabbed interfaces are nice features but do yourself a favor and learn the ins and outs of embedding groups of controls into form. Some frameworks allow you to directly embed one form into another. Others have special containers that can be be embedded.
The point of these is to break up your functionality so you don't wind up with a bloated form class that's difficult to wade through.
I would also spend some time looking at some of the architectural patterns for keeping your business logic separate from your UI. Check out this link for a good starting point.