I'd realised this, yes, when it occurred to me how to fix stacks according to the current implementation:
The option of list view
Hierarchical access to folders in stacks
The option of keeping a designated icon for the stack (a bit like a folder icon)
Don't bother calling it a stack anymore
Really, what's the point in stacks?
Stacks really are rubbish, aren't they.
I'm still trying to figure out the people who think an alphabetical list with access to subfolders is chaotic and wrong and that a big grid of icons is much nicer and easier to find things in.
I mean, different strokes and all, but I find this literally incomprehensible.
I can only conclude that there is something in stacks with the power to infect people's minds and make them insane.
Just use Quay and get it over with. Works pretty much exactly like the old implementation except you left-click instead and you can only use one folder currently. Good enough for me, I just added my Documents folder.
Just use Quay and get it over with. Works pretty much exactly like the old implementation except you left-click instead and you can only use one folder currently. Good enough for me, I just added my Documents folder.
Quay's pretty good. I'm using it... but it still restricts you to only one icon in the dock, unfortunately...
Believe me, I don't just say it without personal experience.
I've been emailing Apple on and on about so many things in the past, not to mention several things that really need sorting out with .Mac - considering I'm a subscriber to .Mac you'd think I'd get at least some "thank you for contacting us, your opinion is important to us"... But no, it's pretty much a void into which all email disappears, never to be heard from again.
Or perhaps Apple is smarter than we give them credit for and it was planned all along, just not ready yet.
Not ready? I seriously doubt it. It should be trivial to implement the reported functionality once the design decisions had settled. The code was there previously.
Not ready? I seriously doubt it. It should be trivial to implement the reported functionality once the design decisions had settled. The code was there previously.
Not willing? Yes, this I can believe.
The code wasn't there previously. Stacks are rendered differently and behave differently than all other interface objects. Something like a drag-n-drop bug found late in the development cycle could easily shelve the feature temporarily.
Either scenario is quite plausible. We simply can't know (without inside info) why it wasn't included in the dot-oh release.
The code wasn't there previously. Stacks are rendered differently and behave differently than all other interface objects.
Of course I don't mean that the code was there previously in the same sense that you probably do. I mean that Apple had the code for stacks and independently the code that handles the hierarchical view from the Dock. I just cannot believe that it could be so time-consuming, with the current Apple's development tools, to make both cooperate.
Quote:
Originally Posted by dfiler
Either scenario is quite plausible. We simply can't know (without inside info) why it wasn't included in the dot-oh release.
Of course. All I am saying is that I am not convinced that technical difficulties were the reason.
Stacks are most definitely accomplished by new code with complex interactions to debug.
I do not question your assertion, it just seems to me that hierarchical view should nothing be more than an add-on, so to say. It is just one face of those complex interactions to debug. Probably not very obvious for everyone, but not even for Apple?
But the interactions are completely different. They both have to be programmed and tested. Grid based and list based stacks are drastically different with hierarchical lists being the more complex of the two.
Stacks allow drag and drop from within a scrollable, hierarchical list. This is quite complex, especially when you figure in things like expose, dock orientation, multiple monitors, spaces, dock icon updating, etc. Debugging such complex interactivity is no easy task.
Stacks allow drag and drop from within a scrollable, hierarchical list. This is quite complex, especially when you figure in things like expose, dock orientation, multiple monitors, spaces, dock icon updating, etc. Debugging such complex interactivity is no easy task.
Not sure if I follow you: are you saying that the hierarchical view through stacks is a more evolved version of the one we had pre-Leopard?
Exactly. Stacks have options and types of interaction than aren't found in menus. All this functionality had to be programmed and tested. It wasn't simply reuse of existing code.
But with that said... who knows. The initial lack of list-view could have been an intentional design decision rather than an a missed implementation or testing deadline.
I'm an optimist so I give apple the benefit of the doubt and attribute the shortcoming to a brief technical snag rather than an intentional design mistake.
Another piece of Windows I wish Apple would pick up on... Being able to contextual-click on pretty much anything, Stacks included. I know Windows doesn't have Stacks but you can right-click on items in the Start menu and act upon those items as if they were just icons in a folder. It would be great to have this facility in Stacks.
Macintosh interaction is generally noun-verb based. Meaning, you first specify an object and then apply a verb to it.
Menu items aren't really objects and thus they don't allow actions to be performed on them. Menu items are more often verbs. Specifying a verb/action on another verb would be confusing and thus isn't part of current GUI paradigm. I'd be surprised if it ever becomes popular in our everyday GUI.
However, with stacks, apple has brought "objects" into what are essentially menus. This opens up a whole new field of interaction techniques. With the menu items being true objects, right-click becomes logical. A contextual list of commands (actions/verbs) can be applied to stack items because they are real objects.
Apple has been pretty good about not blurring the line about what is an object and what is not. This saves users confusion from not knowing which interactions are possible with each item on the screen. The finder sidebar and dock are the two places where people have trouble knowing what types of interaction are possible. This is because items in the sidebar and dock only support some object behaviors and not all. They are by definition only pseudo-objects, and thus a bit unpredictable.
But now that I think about it, menu items housed in the drop down menus from the full screen menu bar will probably never be right clickable. As detailed above, right click is really only suitable for objects. Our current menus don't house objects and thus don't really need right click. I think it would be confusing to mix objects and actions in a single menu structure. How would users know which things are right-clickable? In my opinion, it is best not to mix the two.
That's really interesting dfiler and I'm in complete agreement. I wouldn't expect there to be any right-clicking available in menu items anyway... They're not available in menus in XP either anyway. If you think of the Start Menu and all other parts of the task bar as objects (which they are, like the Dock) then this makes sense. Even though the Start menu opens up in the same way as a menu, it does look different from a menu and works as an object.
If Apple can keep updating the dock and bringing it more in line with other objects in OSX, I will be very happy.
Comments
But, in the original plan, folders in the dock and stacks were two different things...
I'd realised this, yes, when it occurred to me how to fix stacks according to the current implementation:
- The option of list view
- Hierarchical access to folders in stacks
- The option of keeping a designated icon for the stack (a bit like a folder icon)
- Don't bother calling it a stack anymore
- Really, what's the point in stacks?
Stacks really are rubbish, aren't they.I'd realised this, yes, when it occurred to me how to fix stacks according to the current implementation:
- The option of list view
- Hierarchical access to folders in stacks
- The option of keeping a designated icon for the stack (a bit like a folder icon)
- Don't bother calling it a stack anymore
- Really, what's the point in stacks?
Stacks really are rubbish, aren't they.I'm still trying to figure out the people who think an alphabetical list with access to subfolders is chaotic and wrong and that a big grid of icons is much nicer and easier to find things in.
I mean, different strokes and all, but I find this literally incomprehensible.
I can only conclude that there is something in stacks with the power to infect people's minds and make them insane.
Just use Quay and get it over with. Works pretty much exactly like the old implementation except you left-click instead and you can only use one folder currently. Good enough for me, I just added my Documents folder.
Quay's pretty good. I'm using it... but it still restricts you to only one icon in the dock, unfortunately...
http://www.apple.com/feedback/
Ahhh yes, the wonderful "email us at trash@apple.com and that's exactly where your email will go" page
Ahhh yes, the wonderful "email us at trash@apple.com and that's exactly where your email will go" page
Ya yes, let's not communicate, it's all hopeless and nobody cares anyway.
I've been emailing Apple on and on about so many things in the past, not to mention several things that really need sorting out with .Mac - considering I'm a subscriber to .Mac you'd think I'd get at least some "thank you for contacting us, your opinion is important to us"... But no, it's pretty much a void into which all email disappears, never to be heard from again.
10.5.2 Fixes Stacks!
Or perhaps Apple is smarter than we give them credit for and it was planned all along, just not ready yet.
Looks like the dock's about to become really, really good.
Looks like our bitching paid off...
10.5.2 Fixes Stacks!
Or perhaps Apple is smarter than we give them credit for and it was planned all along, just not ready yet.
Not ready? I seriously doubt it. It should be trivial to implement the reported functionality once the design decisions had settled. The code was there previously.
Not willing? Yes, this I can believe.
Not ready? I seriously doubt it. It should be trivial to implement the reported functionality once the design decisions had settled. The code was there previously.
Not willing? Yes, this I can believe.
The code wasn't there previously. Stacks are rendered differently and behave differently than all other interface objects. Something like a drag-n-drop bug found late in the development cycle could easily shelve the feature temporarily.
Either scenario is quite plausible. We simply can't know (without inside info) why it wasn't included in the dot-oh release.
The code wasn't there previously. Stacks are rendered differently and behave differently than all other interface objects.
Of course I don't mean that the code was there previously in the same sense that you probably do. I mean that Apple had the code for stacks and independently the code that handles the hierarchical view from the Dock. I just cannot believe that it could be so time-consuming, with the current Apple's development tools, to make both cooperate.
Either scenario is quite plausible. We simply can't know (without inside info) why it wasn't included in the dot-oh release.
Of course. All I am saying is that I am not convinced that technical difficulties were the reason.
Stacks are most definitely accomplished by new code with complex interactions to debug.
Stacks are most definitely accomplished by new code with complex interactions to debug.
I do not question your assertion, it just seems to me that hierarchical view should nothing be more than an add-on, so to say. It is just one face of those complex interactions to debug. Probably not very obvious for everyone, but not even for Apple?
Stacks allow drag and drop from within a scrollable, hierarchical list. This is quite complex, especially when you figure in things like expose, dock orientation, multiple monitors, spaces, dock icon updating, etc. Debugging such complex interactivity is no easy task.
Stacks allow drag and drop from within a scrollable, hierarchical list. This is quite complex, especially when you figure in things like expose, dock orientation, multiple monitors, spaces, dock icon updating, etc. Debugging such complex interactivity is no easy task.
Not sure if I follow you: are you saying that the hierarchical view through stacks is a more evolved version of the one we had pre-Leopard?
But with that said... who knows. The initial lack of list-view could have been an intentional design decision rather than an a missed implementation or testing deadline.
I'm an optimist so I give apple the benefit of the doubt and attribute the shortcoming to a brief technical snag rather than an intentional design mistake.
Macintosh interaction is generally noun-verb based. Meaning, you first specify an object and then apply a verb to it.
Menu items aren't really objects and thus they don't allow actions to be performed on them. Menu items are more often verbs. Specifying a verb/action on another verb would be confusing and thus isn't part of current GUI paradigm. I'd be surprised if it ever becomes popular in our everyday GUI.
However, with stacks, apple has brought "objects" into what are essentially menus. This opens up a whole new field of interaction techniques. With the menu items being true objects, right-click becomes logical. A contextual list of commands (actions/verbs) can be applied to stack items because they are real objects.
Apple has been pretty good about not blurring the line about what is an object and what is not. This saves users confusion from not knowing which interactions are possible with each item on the screen. The finder sidebar and dock are the two places where people have trouble knowing what types of interaction are possible. This is because items in the sidebar and dock only support some object behaviors and not all. They are by definition only pseudo-objects, and thus a bit unpredictable.
But now that I think about it, menu items housed in the drop down menus from the full screen menu bar will probably never be right clickable. As detailed above, right click is really only suitable for objects. Our current menus don't house objects and thus don't really need right click. I think it would be confusing to mix objects and actions in a single menu structure. How would users know which things are right-clickable? In my opinion, it is best not to mix the two.
If Apple can keep updating the dock and bringing it more in line with other objects in OSX, I will be very happy.