cocoaforge

I don't think a sheet is acceptable here. It'd be huge and wouldn't look right.

Can you mock up what you are thinking of with replacing the drop down though?

sdf wrote: 2.2. Enabling/disabling individual messages should be easy.

This is the problem, I don't see how this is anywhere close to hard.

The_Tick wrote:This is the problem, I don't see how this is anywhere close to hard.

Well, a mock up would take a while, but this I can answer immediately.

Let's assume my complaint is Adium sending me notifications I don't want.

I start at the Growl preference pane. From here, I click the Applications tab and double click Adium. There's nothing on the first tab that helps me, so I click the second tab. Here, there's no obvious listing of the notifications I want to change. There is a popup, but that conceals what I'm looking for. Once you click it, though, you find the notification I want to change.

So, basically, the individual notifications settings are hidden four levels deep (Applications tab, individual application, Notifications, Notification type).

I do not see how that is hard.

The_Tick wrote:I do not see how that is hard.

Well, I don't know what to say. I don't mean to be harsh, but the only explanation I can think of for that is that you're too in love with your design. But it's easy to settle the question of whether it's too hard: Test it and see.

For those who enjoy the NotifyOSX style: I have updated NotifyOSX för Growl 1.1, see here: http://www.interaktion.info/growl-displ ... tifyosx-2/

Great work with Growl 1.1 by the way. It is a huge improvement.

sdf wrote:

The_Tick wrote:I do not see how that is hard.

Well, I don't know what to say. I don't mean to be harsh, but the only explanation I can think of for that is that you're too in love with your design. But it's easy to settle the question of whether it's too hard: Test it and see.

Nah, I mean, if a drop down is hard, then why would Apple ship it with OS X?

I don't see how clicking a couple of things to get what you want is hard, especially when I consider that what we put in the initial tab for the application ticket to be more important for the end user than the other bit in the Notifications tab.

This is not hard. It's normal UI elements provided by Apple. If it were hard Apple would have ditched drop downs years ago.

So maybe the word you are looking for isn't hard, but something else.

The_Tick wrote:So maybe the word you are looking for isn't hard, but something else.

<shrug> Well, popup menus themselves are not a bad thing. They're excellent for choosing options. But I think using them to switch modes is a bad thing. That's what tabs and lists are for. I guess in October, we'll know if Apple thinks using them to switch pages a good idea or not.

At some point you have to ignore what apple does though. So, to me, what you said is a cop-out for the fact that you think something else is better.

We'll await mockups.

thanks for the update! is there any way to disable the close button on the notifications?

hippy dave wrote:thanks for the update! is there any way to disable the close button on the notifications?

Nope, sorry, those are staying.

The_Tick wrote:At some point you have to ignore what apple does though.

One of the advantages you listed for the new interface was "Apple-like," so I thought "Apple has realized it's a bad idea" was a good argument.

sdf wrote:

The_Tick wrote:At some point you have to ignore what apple does though.

One of the advantages you listed for the new interface was "Apple-like," so I thought "Apple has realized it's a bad idea" was a good argument.

Apple-like is a quality to go for, but it's not the end-all. The hud, for instance, is pretty awesome. Pixelmator I'm sure breaks about 50 different rules, per window, out of the HIG though. However, it's very pretty. It also fits with the app and what it's going for, which is more important.

You have to weigh prettyness with functionality and intended audience, is how I see it.

I think the prefpane is currently pretty in this area (with the exception of the back to apps list button). I also think it works towards the focus of getting end users to be able to understand how to use Growl. Growl 0.7.6 was very confusing for end users, 1.1 is the start of us focusing on getting end users to be able to understand it more without us having to explain Growl on the about page, them still not understanding, getting frustrated, and removing Growl in general.

The drop down is not hard to get to, nor is it hard to understand. It also allows for a long name, but up to a point so developers get the idea to not use long method names for that list, and it allows us to have more options per notification in there if need be.

I really am not seeing the downside here. Growl is a system tool, it's designed to allow the user to configure different options. If we go back to a table design, well, we just threw away all the extra room we just got in order to appease a small, yet vocal, minority of the Growl user base who wants to click 2 times instead of 4.

I don't get why this is hard to grasp. We're trying to include more than super geeks in our user base.

The_Tick: it's not that disabling a particular notification is "OMG no way I can handle it hard!!1", but it does take like 5-6 steps, which is way too many IMO. I think that's in general been my most common reason for interacting with the growl preference pane, and it used to take 3 very obvious clicks to accomplish. Also the ability of the two interfaces to accomplish the "disable that annoying pop up for every chat received" task has little to do with regular vs. power users. You keep saying that the new interface is better for newbies, but I just don't buy it. Did you sit down with 5-10 newbies, give them a list of tasks to do in the interface, and watch them interact with it? If you do, I expect you'll come to agree with me. And I finally don't think it's just a small percentage of users who turns off some notifications.

It's undoubtedly too late to make such a design decision, but if it was up to me, I would have information about position and sounds in the "display options" tab, the place where I would naively look for it. And then I would just have users wanting the same display style to have 2 different behaviors just duplicate it in the list with different options, somehow. I would also let users easily disable styles, etc. so that 10+ useless ugly ones wouldn't show in every style dropdown. I can even concede that having the applications in a single list might be simpler for users who never want to disable an individual notification, but I would make opening that app in the list go to a table of notification types, whose properties would all be visible at once.

The biggest problem isn't even necessarily that it takes too many steps. It's just that the steps are non-obvious, each view along the way is under-populated with data, and the whole interface is very click-rich but information-poor: all the useful information is spread out over hundreds of different little views, only one of which can be seen at once.

And again, not trying to troll here. I've had some experience designing interfaces, and I fall into the same traps all the time. It takes huge amounts of patience and ingenuity to make an optimal interface. (As a side note: I recommend anyone who is working on graphical interfaces go read through a couple of Tufte's books on information design)

jacobolus wrote:Did you sit down with 5-10 newbies, give them a list of tasks to do in the interface, and watch them interact with it?

Yes:

The_Tick wrote:I showed Growl to a first time user, a custom build that had asked me to help her out with her new computer. I showed .7.6 to another new user. They both got the concept after I explained it, but the one who used the custom build liked Growl more than the .7.6 version person did. I cannot stress enough that both people did not care about per application stuff, they just wanted to enable/disable things. This is also why I felt that a big table with big icons (people identify shapes faster than text, there's a study somewhere about that)

Albeit, not with 5-10 people. There's not that many mac people that I know of in Houston. At least, newbie mac people.

Don't get me wrong guys, I'm sure this could use improvement, but it's my opinion that what we have now is easier for the end user, and a bit tougher than before for the power user. If you guys can come up with a mockup that's better, I'm all for it.

Anyhow, we've beaten the horse enough on this I think. You guys know my 4 requirements from page 1. If you come up with something, make a thread or post to the google group.

sdf wrote:Well, popup menus themselves are not a bad thing. They're excellent for choosing options. But I think using them to switch modes is a bad thing.

Thanks for clearly summarizing of one of my first negative impressions after upgrading to 1.1 and exploring the app prefs changes.

jacobolus wrote:The biggest problem isn't even necessarily that it takes too many steps. It's just that the steps are non-obvious, each view along the way is under-populated with data, and the whole interface is very click-rich but information-poor: all the useful information is spread out over hundreds of different little views, only one of which can be seen at once.

And thanks for summarizing something else I hadn't quite found a good description for.

A few minutes ago I posted a suggestion to the google group for adding an "app prefs have been modified" indicator to the main apps tab. It's based on having just seen/used 1.1 for the first time when it was officially released a few days ago so I'm barely familiar with the changes. And I've never been to deep into tinkering with Growl though I can grok its UI issues fairly well and am interested in possible improvements.

That's all I want to say here now that The_Tick considers this thread's horse beaten. Anything more would risk being redundant relative to previous discussion anyway.

EDIT: Nevermind - I think one of my scripts hung up Applescript - after a restart everything worked fine... Thanks!


----
original:
Did 1.1 break Applescript? None of my scripts work now, and even the generic sample script on the website doesn't work. When run from script editor it hangs for about 2min then I get a 'GrowlHelperApp got an error: AppleEvent timed out.'

Other than that - great update!

Craig

"rk wrote:
Growl 1.1 looks great, but I have one question: Where's the GUI option to enable and disable logging of Growl notifications?


This was removed in 1.1 from the pref pane. That was more a developer feature than a user feature. Redone logging is certainly possible in a future release (I recall a patch recently about this.) That all said, the feature is still there, and you can turn it on in the preferences of the BeepHammer developer tool."

1. So where can I get "Beephammer?" I'm not a developer, I just want the "enable logging" feature.

2. I use logging to keep a running text file log of SuperDuper backups on the desktop of each computer. I've had enough problems with email notifications (some OS X related, some Grown related, some Earthlink down time related ;-), that I need a better more consise log than the regular console log. I recommend that it be put back into regular Growl, even if it is a somewhat hidden option.

Ed Oates

edoates wrote:"rk wrote:
Growl 1.1 looks great, but I have one question: Where's the GUI option to enable and disable logging of Growl notifications?


This was removed in 1.1 from the pref pane. That was more a developer feature than a user feature. Redone logging is certainly possible in a future release (I recall a patch recently about this.) That all said, the feature is still there, and you can turn it on in the preferences of the BeepHammer developer tool."

1. So where can I get "Beephammer?" I'm not a developer, I just want the "enable logging" feature.

2. I use logging to keep a running text file log of SuperDuper backups on the desktop of each computer. I've had enough problems with email notifications (some OS X related, some Grown related, some Earthlink down time related ;-), that I need a better more consise log than the regular console log. I recommend that it be put back into regular Growl, even if it is a somewhat hidden option.

Ed Oates

1. BeepHammer is detailed here: http://trac.growl.info/wiki/BeepHammer. Alternatively you can run the following in a Terminal window to turn it on - defaults write com.Growl.GrowlHelperApp GrowlLoggingEnabled -int 1

2. As I stated in the quoted text, redone logging is possible in a future release. As it stands, the old version is not returning to the pref pane.