in interface builder what is accessibility menu for? - xcode

with the newer sdk we can see a menu named accessibility in identity inspector.What does it do and how we can use it in application?

That menu is part of the accessibility interface, which allows you to make your application more usable by those with disabilities.
Through the various components, including attributes like labels to hook in to the VoiceOver system, traits to describe a control's position and state, hints to describe the uses of a control, zoom, high contrast modes, and much more, you can significantly improve the accessibility of your application (in addition to providing some benefits to those who happen to like these features even if they have no disability).
The Accessibility Programming Guide for iPhone OS provides all the details and a great jumping off point to get started with accessibility in iPhone development.

Related

How to include iOS8 extensions when using a custom share UI?

There is any way to access sharing extensions without popping the default UIActivityViewController?
I couldn't find one, but asking just in case.
In case not, i have another question.
How are you planing to adapt your app's custom sharing interfaces to this restriction?
You cannot access Share/Action extensions without using UIActivityViewController. In iOS8 sharing area of the activity view controller is the only entry point for share extensions.
From Apple docs.
Each of which is tied to an area of the system, such as sharing,
Notification Center, and the iOS keyboard. A system area that supports
extensions is called an extension point. Each extension point defines
usage policies and provides APIs that you use when you create an
extension for that area. You choose an extension point to use based on
the functionality you want to provide.
The best you can do is to provide a share menu with two options to launch app's custom sharing interface and UIActivityViewController. Bad UX but I don't know any other way.

Window docking advice for Mac

I'm from a Windows programming background when writing tools, but have been programming using Carbon and Cocoa for the past year. I have introduced myself to Mac by, I admit it, hiding from UI programming. I've been basically wapping my OpenGL code in a view, then staying in my comfort zone using my platform agnostic OpenGL C++ code as usual.
However, now I want to start porting one of my more sophisticated applications to Mac OS.
Typically I use the standard Visual Studio dockable MDI approach, which is excellent, but very Windows-like. From using a Mac primarily now for a while, I don't tend to see this sort of method used for Mac UIs. Even Xcode doesn't support the idea of drag and drop/dockable views, unfortunately. I see docked views with splitter panels, but that's about it.
The closest thing I've seen to the Visual Studio approach is Photoshop CS4, which is pretty nice.
So what is the general consensus on this? Is there are more Mac-like way of achieving the same thing that I haven't seen? If not, I'm happy to write a window manager in Cocoa myself, so that I can finally delve in an learn what looks like an excellent API.
Note, I don't want to use QT or any other cross-platform libraries. The whole point is that I want to make a Mac app look like a Mac app, leave the Windows app looking like a Windows app. I always find the cross-platform libraries tend to lose this effect, and when I see a native Mac UI, with fancy Cocoa transitions and animations, I always smile. It's also a good excuse for me to learn Cocoa.
That being said, if there is an Open Source Cocoa library to do this, I'd love to know about it! I'd love to see how someone else achieves this, and would help smooth the Cocoa learning curve.
Cheers,
Shane
UPDATE: I forgot to mention a critical point. I support plugins, which can have their own UI to display various plugin specific information. I don't know which plugins will be loaded and I don't know where their UI will live, if I don't support docking. I'd love to hear people's thoughts on this, specifically: How do I support a plugin view architecture, if the UI can't change? Where do I put the plugin views?
Coming from a Windows background, you feel the need to have docking windows, but is it really essential to the app? Apple's philosophy (in my opinion) is that the designer knows better than the user how things should look and work. For example, iTunes is a pretty sophisticated app, but it doesn't let you change the UI around, change the skin, etc., because Apple wants to keep it consistent. They offer the full view, the mini player, and a handful of different viewing options, but they don't let you pull the source list off into a separate window, or dock it in other positions. They think it should be on the left, so there it stays...
You said you "want to make a Mac app look like a Mac app", and as you pointed out, Mac apps don't tend to have docking windows. Therefore, implementing your own docking windows is probably a step in the wrong direction ;)
+1 to Ken's answer.
From a user perspective unless its integral to the app like it is in Adobe CS or Eclipse i want everything as concise as possible and all the different options and displays out of my way so i can focus on the document.
I think you will find with mac users that those who have the "user skill" to make use of rearranging panels will in most cases opt for hot key bindings instead, and those who dont have that level of "skill" youre just going to confuse.
I would recommend keeping it as simple as possible.
One thing that's common among many Mac apps is the ability to hide all the chrome and focus on your content. That's the point behind the "tic tac" toolbar control in the top right corner of many windows. A serious weakness of many docking UIs is that they expect you to have the window take up most of the screen, because the docked panels can obscure content. Even if docked panels are collapsable, the space left by them is often just wasted and filled with white space. So, if you build a docking panel into your interface, you should expect it to be visible most of the time. For example, iTunes' source list is clearly designed to be visible all the time, but you can double-click a playlist to open it in a new window.
To get used to the range of Mac controls, I'd suggest you try doing some serious work with some apps that don't have a cross-platform UI; for example, the iWork apps, Interface Builder or Preview. Take note of where controls appear and why—in toolbars, in bottom bars, in inspectors, in source lists/sidebars, in panels such as IB's Library or the Font and Color panels, in contextual HUDs. Don't forget the menu bar either. Get an idea of the feel of controls—their responsiveness, modality, sizing, grouping and consistency. Try to develop some taste—not everything is perfect; just try iCal if you want to have something to make fun of.
Note that there's no "one size fits all" for controls, which can be an issue with docking UIs. It's important to think about workflow: how commonly used the control would be, whether you can replace it with direct manipulation, whether a visible indication of its state is necessary, whether it's operable from the keyboard and mouse where appropriate, and so forth. Figure out how the control's placement and behavior lets the user work more efficiently.
As a simple example of example of a good versus bad control placement and behavior in otherwise-decent applications, compare image masking in OmniGraffle and Keynote. In OmniGraffle, this uses the Image inspector where you have to first click on an unlabeled button ("Natural size") in order to enable the appropriate controls, then adjust size and position away in a low-fidelity fashion with an image thumbnail or by typing percentages into fields. Trying to resize the frame directly behaves in a bizarre and counterintuitive fashion.
In Keynote, masking starts with a sensibly named menu item or toolbar item, uses a HUD which pops up the instant you click on a masked image and allows for direct manipulation including a sensible display of the extent of the image you're masking. While you're dragging a masked image around, it even follows the guides. Advanced users can ignore the HUD entirely, just double-clicking the image to toggle mask editing and using the handles for sizing. It should be easy to see, with a few caveats (e.g. the state of "Edit Mask" mode should be visible in the HUD rather than just from the image; the outer border of the image you're masking should be more effectively used) Keynote is substantially better at this, in part because it doesn't use an inspector.
That said, if you do have a huge number of options and the standard tabbed inspector layout doesn't work for you, check out the Omni Group's OmniInspector framework. Try to use it for good, and hopefully you'll figure out how to obsess over UI as much as you do over graphics now :-)
(running in slow motion, reaching out in panic) Nnnnnoooooooo!!!!!
:-) Seriously, as I mentioned in reply to Ken's excellent answer, trying to force a "Windowsism" on an OS X UI is definitely a bad idea. In my opinion, the biggest problem with Windows UI is third-party developers inventing new and inconsistent ways of presenting UI, rather than being consistent and following established conventions. To a Mac user, that's the sign of a terrible application. It's that way for a reason.
I encourage you to rethink your UI app's implementation from the ground up with the Mac OS in mind. If you've done your job well, the architecture and model (sans platform-specific implementation) should clearly translate to any platform.
In terms of UI, you've been using a Mac for a year, so you should have a pretty good idea of "the norm". If you have doubts, it's best to post a question specifically detailing what you need to present and your thoughts on how you might do it (or asking how if you have no idea).
Just don't whack your app with the ugly stick by forcing it to behave as if it were running in Windows when it's clearly not. That's the kiss of death for an app to Mac users.

Styling a BlackBerry Application to Look Like an iPhone

I am porting an application from iPhone to BlackBerry. BlackBerry apps tend not to look as polished as iPhone, but naturally, I would like to maintain as much polish as I can, without breaking any important UI conventions. Are there any UI components that can help with this?
NB. I am planning to follow all important UI conventions. For example, I will use the BlackBerry Menu instead of a tab bar for providing access to help and some other advanced options.
Links
Make BlackBerry UI Components Look Like iPhone Components
You can extend blackberry controls with custom drawing, or implement own one extending Field class. Also you may draw a bitmap background (skin) for each control state.
See also
UPDATE How to – Implement advanced buttons, fields and managers
naviina - iPhone-style Field for Blackberry
SO - Blackberry User Interface Design - Customizable UI
This is one of those instances where providing the answer to the question you have asked is tantamount to helping commit a crime!
That sounds dramatic but as developers we have a responsibility to provide the user with a good experience - this means an experience that conforms to their expectations and makes it easy for them to Get Things Done!
I know how pissed off I get when developers implemented custom interfaces in desktop applications and there I have an entire keyboard and mouse to help me navigate!
If all I have is a touchscreen or a tiny trackball and buttons then I am going to be even more pissed off.
Unless you are revolutionising user input and design on Blackberry devices - which, no offence, I doubt you are - then stick to the conventions and guidelines for that platform.
Make your software easy to use and easy to learn - do not ask a user to relearn their own platform to use your app!

GUI for creating fullscreen web applications

Desktop GUI builder tools such as Qt Designer and Glade let me easily design a resizable interface with menus, shortcuts, tab order, status bar, etc
Is there an equivalent tool for the web?
I am not after building a typical web interface where you scroll down to view all the content, but a fullscreen interface with menus at the top and status bar at bottom.
Here is an (awesome) example fullscreen web app: http://desktop.sonspring.com/
The Flash Platform would probably give you a more familiar environment to develop for. The Flex framework provides a complete framework for developing sophisticated applications and Flex Builder (built on top of Eclipse) gives a UI 'designer' to build large parts of your app using the drag & drop philosophy.
For the kind of interfaces you're describing, ExtJS is quite a nice library. While there is not a GUI interface designer yet, there is reportedly one in the pipeline.
While the widget library is available under GPL3 (which caused some controversy), it's also available via commercial licenses. The interface builder will cost some kind of money.
Check out the demos, there is a desktop sample very similar to the one you referenced in your question.

GUI framework for automatic resizing

I want to build a desktop app where the size of both the window and the content is resized automaticly according to the resolution of the monitor. I know it can be done easily with the docking features of .NET Forms, but my customer insists on going with Linux so I can't use it.
I tried Flex & Air, but the content is not resized automaticaly when I put the app in fullscreen or in another resolution (the app goes full screen but I still have tiny buttons). Now, I am looking at Qt and Gtk...
Is there a GUI framework that can do that? I don't care about the programming language.
Also, since the app will go in a bar it would be nice to be able to customize easily the skin. (like in Flex, WPF, etc.)
Regards,
Pascal
An excellent place to start is understanding how the Screen class works: MSDN Even though that is .Net, it will give you an idea of how the screen size, dpi, etc. can be obtained. In addition that information should translate to the Mono platform. Since your client is insisting on Linux, you should look at MonoDevelop and then possibly the GTK# framework. My understanding is that GTK# is not a very friendly (that is pretty) development system (yet).
See:
MonoDevelop
GTK#

Resources