Dunderklumpen wrote:bengoodger wrote:Dunderklumpen wrote:I for one would like to see more developers just spending some time in here - from time to time.
Aside from the work that Pierre has done improving Bookmarks and digging around in the toolkit, patches from individual contributors and the infrasturcture work Brian has been doing on an ongoing basis, Firefox is basically just me at the moment. I don't think many people understand or appreciate that. I don't think people realize that I have to:
For those that want to complain, look at the list above. Could you do any better?
-Ben
Complaint is a sign of that people care. You can either look upon them in a positive manner and try to deal with them - within in reason - or you can look upon them as just nagging and whining. I for one can fully understand the lack of time and the many things each and everyone has to do - but I see at least two other names in there. Impossible to get them involved? If they are involved in branding and marketing there are stuff in here that they could answer.
And this was not intended at you or anyone else so do not take it personally - but the simple fact that you now, in this thread has provided us with very usefull information will, and have cleared things. Wich is my point - communication is good and makes things better.
OK... while we're being productive...
here's a framework for discussing any decision that is made by the project that people want to talk about:
- try and think about why the decision was made, if possible with reference to documentation on mozilla.org, such as the charter, roadmap, etc. I think I'm generally pretty good at explaining why things have been done in here as well when I enable new features.
This usually means putting one's own personal thoughts aside for a moment and considering a different criteria. It's good to try be objective like this at least once a week
It helps keep one's mind from rusting shut.
- what are the assumptions that were made when the decision was made? (1)
- were there reasons beyond our control that caused the decision to be made? (2)
- and any number of other mental excercises.
(1) For example, Myk came to me the other week and asked me about the "Save Link to Disk..." context menu item. Firstly, he correctly pointed out that the item had an ellipsis on the end of it when it did not prompt for any user input. Secondly, he said that when he used that function he was primarily saving files into a specific, that-time-only location, such as saving patches from bugzilla, and the default behavior of automatically saving to Desktop when selected was very counter-productive. He said he didn't want to turn off the auto-save behavior because he liked it when clicking on links. Myk asked me some hard questions about the
assumptions I had made when I made the right click menu item auto-save... the primary one was that at that time our content type sniffing wasn't as good as it is now, and that often just clicking on a link would result in garbage being displayed. Now that we've fixed that bug, that assumption no longer has a basis, and thus the context menu item is a good place to stick an action that differs from the default single link click action. (Note: I haven't actually done this yet, but I will do so soon). This is a good case where investigating the assumptions made in designing a feature have caused an improvement. Don't be afraid to question decisions we've made, but try to ask good questions!
(2) As an example, in the name change case, Brendan had promised the database folks that we'd change the name by 0.8. Once a word has been given, legal standing, project dissimilarity etc go out the window if you want to remain credible. We had no choice. We had to keep our name choice quiet too because we did not want to jeopardize legal negotiations allowing us use of the name in various markets. Finally we wanted to keep the fact that we were changing the name at all quiet since we wanted to try and deflect as much of the inevitable negative publicity as possible by having a strong release to back it up. That seems to be working.
Also, when people talk about features in the UI, it'd be helpful if people thought of the context in which they were using a feature, and what they were trying to do, before insisting that a particular piece of UI is implemeted. For instance, rather than just saying we need a new window for this, try and think about your problem not as a lack of that window, but as the task you were trying to achieve. This brings you closer to "contextual design," a highly regarded methodology for UI design. Think about your problem from many angles, explore alternatives, and present them all. There may be gems, even among solutions that are not completely adopted!