This seems like an easy thing but I'm coming mainly from the Win world to Mac. Is there a way I can make notification alerts bigger? Or install a different App that will do this?
Right now if I notice them, I see a little alert boxes in the upper right of the desktop when a calendar appointment comes up. I have no sound...and might not be sitting at the desk anyhow...so if I have a lot of windows up and happen not to look at the upper right (actually of two screens)...I just miss the notification. I'd like to have a lot of control over those pop ups. Size, perhaps different actions (flash the screen until acknowledged?) etc. At the very least it's just not useful to me at all unless I can increase the size of the popups somehow. Jack up the font size? Again, maybe some different app that I need? Etc.
Thanks in advance! Man I can't seem to hit on the magic Google input to return anything useful on this topic.
After some research, amazingly it seems there is no way to customize OS X native notification display. The best I have come up with, in theory but not personally tested, is to add a third party notification app called Growl which is much more customizable, and then add an app that produces Growl notifications based on iCal entries. I haven't done this yet because it seems like a lot of hassle and overkill...so for now I've been living with the native notifications. When I have time I'll try the Growl route...unless I see something different posted here.
Related
Apologies for an 'open' question, but can anyone provider pointers on how to 'dock' my app to the Android Wear watch face?
Essentially, I want users of the application to be able to swipe left to right (or vice-versa) from the edge of the screen to open the application, compared to having to scroll the list of applications after tapping the watch face.
I've seen this implemented in another wear app, but don't know the right terminology to produce meaningful results in Google. Is it a wallpaper service, specific view type, touch listerner service etc?
Many thanks.
You can't receive touch events inside the WatchFaceService, touch delivery is disabled.
I can't say for sure how the app you saw implemented the desired behavior, but it probably did by inserting views directly into the WindowManager from a Service.
Checkout this youtube video: https://www.youtube.com/watch?v=S3vHjxonOeg
I don't know how well the Standout library does its job, but it should give you enough examples to figure out yourself, how to add views to the WindowManager.
Most other extensions have functionality (such as photo-editing, posting to social networks, etc) for which it makes sense to have a parent app.
But for the simplest of keyboard extensions, without any (user-facing) data management or other requirements, I don't understand what the parent app should do.
Just having a "Hello" splash screen seems like a cheat. But is this what Apple expects, at least when it comes to keyboard apps (the simplest ones)?
P.S:
Considering the documents are openly available here, I hope there won't be an NDA issue blocking this question.
I'm not sure if there is another SE sub-site on which this question is more appropriate. However, if necessary, I'd be glad to move the question.
I was looking for a keyboard-specific tag, but none seemed right. UIKeyboard seems specific to the earlier "default" iOS keyboard.
Since the keyboard needs an app, maybe use it as a way for users to try your keyboard without exposing content from other apps to it, at first. It might be important for you to teach users how to use your new keyboard.
Also, since Apple is emphasizing privacy (especially since the potential for key logging keyboards may seem high to the user), you also could display a privacy policy in your demo app. Or at least have an explanative mention of what you do with their typed text other than entering it into the whatever app your keyboard is currently running in.
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...
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.
I'm using ruby-libnotify in a Ruby GTK app, and it works great to create a bubble popup in Ubuntu. I'm on Hardy, and it all works great. Then I had others try the app on Jaunty, and instead of a bubble popup with the new Notify-OSD system, as I expected, the notification turned into a dialog box.
I looked into it, and found the Ubuntu wiki states that the problem is because I set a timeout of 0:
Some programs specify an expire_timeout of 0 to produce notifications that never close by themselves, assuming that they can be closed manually as they can in notification-daemon. Because this is usually done for a message that requires response or acknowledgement, Notify OSD presents it as an alert box rather than as a bubble.
Is there a way I can use libnotify in some way to have a normal bubble with a "never expire" timeout? I would actually prefer it if I could use the old notification system, even, since Notify-OSD doesn't seem to support permanent bubbles at all.
It is unacceptable to have the dialog for me, as it doesn't stay over all windows, so the user won't see the popup right away, necessarily (which is the whole point of using the bubble popup).
It looks like you are just trying to use Notify-OSD for something it was not designed for. Notify-OSD bubbles are informational and transient, meaning that no critical information should be put in them as they are made to be ignorable.
According to the Ubuntu Design Guidelines, it looks like you are trying to make a morphing alert box, which should suit your needs nicely.
Sort of a sideways answer, but perhaps if the notification API doesn't quite map onto what you want to do you should look into using a more general library that allows you to draw your own on-screen bubbles. xosd comes to mind, though I remember it to be quite limited, but perhaps there are other options...
I remember using some command line tool to display notifications. You could just call it using system or ``.