Re: [Ayatana] progress window chrome
Hi Spike, On Tue, Dec 7, 2010 at 06:39, Spike Burch wrote: > the purpose is probably following the gnome HIG, which says that those > windows must have a titlebar > I'm familiar with that part of the HIG. ( http://library.gnome.org/devel/hig-book/stable/windows-progress.html.en ) It doesn't specify title bars, it says "window title". It also focuses on the content of the title, not on how thick the chrome should be.. I think this here is also interesting: http://live.gnome.org/UsabilityProject/HIG/ThreeZero/LondonHackfestNotes see: "What the HIG isn't" ;) The indication of progress is receiving some attention in the design community, which is of essential importance imo. There's nothing less appropriate than to keep a lady waiting with no notice.. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] progress window chrome
Discussions about an eventual "progress indicator" aside, I think this is the kind of thing modal dialogs are meant to eliminate. http://people.freedesktop.org/~david/gnome-shell-modal-dialogs.png -Original Message- From: frederik.nnaji To: Ayatana List Sent: Mon, Dec 6, 2010 6:43 pm Subject: [Ayatana] progress window chrome what purpose has the titlebar in the attached image? I can only imagine that it is meant as a drag handle.. anybody? ___Mailing list: https://launchpad.net/~ayatanaPost to : ayat...@lists.launchpad.netunsubscribe : https://launchpad.net/~ayatanaMore help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Do You Use Gwibber?
Finally, it would be really nice if Gwibber pulled in my most current status update from Identi.ca and placed it into the Me menu, so I could see what my current status is when I go to update it. Interestingly enough, this has already been part of the specification for a long time now: https://wiki.edubuntu.org/MeMenu#Broadcast field "The default contents of the field depends on what your last posting was to each of the set up broadcast accounts. - If the last posting was the same to all broadcast accounts (for example, if you have only one broadcast account item set up), the default contents of the field should be the text of that last posting. - In all other cases, the default contents of the field should be nothing." ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Do You Use Gwibber?
I use Gwibber a lot. One thing I didn't like about the Gwibber integration with the Messaging Menu was how it showed message-specific entries instead of box entries with unread counts like the Evolution integration does. Ken Van Dine recently fixed that and I'm very happy for that. As for the entry in the Messaging Menu, if it had character counting and url shortening I'd be using it a lot more, because it makes sense: I shouldn't need to explicitly open Gwibber to post a message, just like I shouldn't need to explicitly open my contact list just to change my status. I like the idea of the Messaging Menu being an app-independent inbox and the Me Menu being an app-independent outbox. That's why I'd prefer that the evolution "compose" entry was in the Me Menu. -Original Message- From: frederik.nnaji To: Ayatana List Sent: Mon, Dec 6, 2010 5:59 pm Subject: [Ayatana] Do You Use Gwibber? esteemed readers, Do you use Gwibber? It would be quite gratifying if this thread could produce some statistics or opinions. I'm currently evaluating the role of Gwibber in the Ayatana subsystem. We currently have Mail and IM portrayed by two seperate icons in the panel: 1) the envelope -> Mail -> Messaging Menu 2) the speech bubble -> IM -> Me Menu Please respond, if you have the time... I'd welcome opinions, symbolic icons for Gwibber or simply a boolean response ;) ___Mailing list: https://launchpad.net/~ayatanaPost to : ayat...@lists.launchpad.netunsubscribe : https://launchpad.net/~ayatanaMore help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Launcher' icons size to big
Jason, while we're at this subject, could you please tell if Unity is going to follow the WM_CLASS "emergency fallback" that Docky currently uses? Since Unity is going to use those big icons, I'm particularly worried whether it will always ensure overriding small icons with large enough ones, even when the window is not directly associated to a .desktop file. -Original Message- From: Jason Smith To: Martín "A. Casco" Cc: ayatana Sent: Sun, Dec 5, 2010 7:05 pm Subject: Re: [Ayatana] Launcher' icons size to big On Sun, 2010-12-05 at 21:47 -0300, Martín A. Casco wrote: > I understand your point. But just an example, since I use Ubuntu (from > Hardy), I always used AWN and 32 x 32 pixels for icon's launchers and > never have fuzzy problems... Even with Cairo and Docky. I wrote docky, trust me, it happens :) > > But, if we use 52 x 52 small screens will loose to much space on > launcher, and auto-hide can't be the solutions, for many users like > me, auto-hide is not used.. Compared to the old launcher you lose an extra 2-4 pixels horizontally. I understand then point about horizontal space. I believe a better hiding mode may be useful for you. I hope to have intellihide ready soon. > > Even more, with 52 x 52 icon's size, we can't add more apps to the > launcher, I know the option arrange icons when we have a lot of apps > on launcher or to many apps open, but this option is very unusable, > it's look nice, but it's unusably.. 52x52 vs 48x48 makes no difference in terms of number of vertical applications on the launcher in a standard netbook screen. The last once folds a tiny bit sooner is all. I should note the code is completely flexible in icon sizing so we can do resolution independent UI in the future. > > Bets, > > El dom, 05-12-2010 a las 18:53 -0500, Jason Smith escribió: > > There are unfortunate limitations on icon sizing in Linux. We are > > stuck > > with 24px, 32px, 48px, and 64px icons. We can interpolate in > > between, > > however this will make it fuzzy. Further 32x32 is not a good option > > since a lot of applications only ship a 24, 48, 64 set of icons. > > Further, svg's while scalable, do not scale all that well either. > > What > > are designed to be 1px lines end up being fractions of pixels, > > making > > them fuzzy as well. > > > > For the compiz version of Unity it was then decided to use 48x48 > > icons, > > with a 2 pixel border in the tile. This represents a growth in tile > > size > > from mavericks 48x48 to Natty's 52x52. The icons do *look* a lot > > bigger > > though because the icon fills a lot more of the tile now. In reality > > however, the icons are only 8% bigger. Some of this loss can be made > > up > > for by a smaller padding on each side of the launcher. > > > > If you look at the launcher in Maverick you will see the icons are > > fuzzy. Be warned though, once you notice this, you can never > > un-notice! > > > > To be truly scalable, Icon authors need to make svg's, and svg needs > > a > > way to denote a line has a fix pixel size. Until this is both > > possible > > and completed, we are stuck in the world of fixed icon sizes... or > > shipping lots of icons. -- Jason Smith | Desktop Experience Team GNOME Developer Canonical USA Inc. T. +1.248.756.6266 | jason.sm...@canonical.com Ubuntu - Linux for human beings | www.ubuntu.com ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] More complete Applications view
Hi Vincent, thanks a lot for sharing your idea! The home of the Dash can definitely be a good place for more sophisticated activity launchers and for surfacing content in general. We are exploring different possibilities around this, so it's great to see that people here are liking it that much! Thanks, chr On Fri, Dec 3, 2010 at 10:04 AM, Vincent Moulin wrote: > Hi, > > Here are my ideas about the Unity applications view. This is not perfect > and finished, but my goal was just to show other options and inspire. > > http://dropbox.nilux.org/unity-app-view.pdf > > Feel free to comment! I can provide the original SVGs if needed. > > Cheers, > > Vincent Moulin > > > ___ > Mailing list: https://launchpad.net/~ayatana > Post to : ayatana@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ayatana > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Seeking feedback on professional video import UX design
On Mon, Dec 6, 2010 at 2:49 AM, Matthew Paul Thomas wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Jason DeRose wrote on 02/12/10 12:15: >>... >> https://wiki.ubuntu.com/AyatanaDmediaLovefest >> >> If you wish to give me feedback, I have a giant favor to ask: if you >> find yourself critical of this design and don't yourself have >> experience with a high-volume pro use-case like this, please first ask >> yourself whether you're truly empathizing with the pro user in this >> scenario. > > That might be why you've received no feedback here so far. The > intersection of Ubuntu design enthusiasts and professional photographers > is rather small. > >> A misunderstanding here is a totally innocent mistake, but >> it happens often and unfortunately never leads to the feedback I need >> to improve this design for the pro user in question. >>... Thanks for taking the time to respond, both here and on #ayatana. > To reiterate what I said on IRC, I think using either notification > bubbles or a status menu for this is inappropriate. A notification > bubble is inappropriate because the moment at which you want to know how > many photos you've imported so far is not necessarily during the brief > period that the bubble is visible. And a menu is inappropriate because > you can't do anything else while you're viewing the things inside it. It's not so much that the user needs to know, it's that they need to be reassured... which will help them relax, reduce mental workload. Which might sound silly, but pro users are truly paranoid and delicate creatures. I've experienced it myself and you don't need that high of a workload before you start to get "the data crazies". I didn't make it clear, but in my scenario there will very likely be a person editing at the workstation. Several takes are made of a shot, then cards are imported and someone will do a rough edit as subsequent takes are in progress. The director and DP can then watch the rough edits... if there are problems and they want to make adjustments, they can do so while the scene is still setup, while it's as cost effective as possible. There might be dozens of these iterations in a single day of shooting. When someone is there editing, I think NotifyOSD strikes a wonderful balance between reliably capturing the user's attention yet not distracting them. It's all because the notifications are non-interactive. They're strangely soothing, IHMO. (Mad props to those who designed them so well.) The notification is only displayed when the final card in the parallel batch completes, when all, say, 4 cards can be removed and 4 new onces inserted. Granted the details of what's inside the RenderMenu are a bit half baked at this stage, but I feel setting the RenderMenu to STATUS_ATTENTION when there are active imports is very important... importing is critical operation that the user must not physically interrupt till complete. When in doubt, a quick glance at the top-left corner is all it takes to check if there is an active import. I also think it's very important that there *not* be progress bars visible. There's a "tug" to them that is just too distracting, IHMO. We want the user to get work done, not watch files be imported. And we don't want the user jumping the gun at 99.9%. I think there is serious advantage to not giving the user any warning that an import is about to complete Anyway... > I suggest instead investigating layouts for a window that lists import > sessions, with columns for time, number of photos imported, size, and > number of duplicates found. My problem with this is that assuming the user is using a maximized application, they wont see this window. I also think the window is a bit invasive, captures too attention. I feel the sweet spot is capturing *just* enough attention to accomplish what is needed. And to me NotifyOSD and and application indicator seem a good fit. All the same, it would be a small effort to try both approaches, get feedback from the users. If you ever have a mockup of what you had in mind for said window, I'd love to see it. I know this is a very specialized use case and it might seem like I'm splitting hairs, but it's also a use case where small improvements can make a big difference to the user. Thanks again for your input! I'll add your suggestion to the wiki page. > - -- > Matthew Paul Thomas > http://mpt.net.nz/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkz8sZ4ACgkQ6PUxNfU6ecqNRgCfWrQhor+PjG46tNVij1lP38e5 > SpsAniNqyDHZ908GRPmDtL2bvkxysVtg > =9f1F > -END PGP SIGNATURE- > > ___ > Mailing list: https://launchpad.net/~ayatana > Post to : ayatana@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ayatana > More help : https://help.launchpad.net/ListHelp > __
