On Jan 24, 2010, at 3:26 PM, Brent Simmons wrote: > On Jan 23, 2010, at 8:59 PM, Mason Mark wrote: > >> On Jan 23, 2010, at 7:34 PM, Brent Simmons wrote: >>> >>> PS Should the code be written in a way that doesn't preclude this feature? >>> My personal opinion: yes, since in this case that's just good architecture. >> >> The crux of my argument is just that supporting multiple viewers, on >> balance, is better than limiting their number to only one. So if it could be >> done for 1.0, great, and if not, then okay get it into some future version. >> [...] >> So if it's just a choice to make, and doesn't materially impact the coding >> workload, why not consider the angles and just make that choice up front? > > It *probably* doesn't impact the coding. But it's software -- everything is > research. We don't know for sure. Every feature is a risk by definition. > > But let's assume it doesn't affect the coding. Then you have the testing > burden. > > With just one main window, you have to test with 0 and 1 window open. If you > allow multiple windows, you have to test with 0, 1, 2, and 3 windows open. > Not *too* bad -- we can handle that. > > But we also have to test with *100* windows open. Because that's just what > happens whenever you allow multiple of something. (There are people who have > 20,000 tabs in my app. Whenever you allow multiples of something, there will > be people who go far, far beyond whatever you expected.)
True! If those are the things that end up meaning we can't get it into 1.0 then fine, so be it. I think the feature (multiple full-fledged viewer windows) is very desirable, and that we shouldn't decide against the idea for reasons *other* than "we don't have time to properly implement that yet". I think virtually all of the pros and cons have now been discussed in this thread, which I will now force myself to re-read in its entirety and roughly summarize below. (Yes, I guess I am trying to bring this thread to its natural conclusion.) Most people were against the idea initially when the thread started, or when they started reading the thread, but many gradually came to agree that it's potentially very useful/powerful to have every viewer window be it's own perspective that you can control in all aspects, to use momentarily or over the course of days and weeks. Some people still don't like the idea, and it's true that we lose a bit of purity of design and simplicity. However, by creating new viewers only explicitly, we can minimize the negative impact to those who don't use the feature, and it comes out to be a solid net win. If the question has now come down to 'can we do it for 1.0 or not', then I am glad. (We're maybe not actually there yet, I suppose.) As you say, you never know with software. But I don't really look at supporting multiple viewers as an additional feature, per se--it's more like a different implementation of the same feature as a main window would be: reading your email, in the context that contains it. I concede that an implementation that allows an arbitrary number of windows is more complex. But not sooo much more complex, especially if that's how we decide to proceed at the beginning. It probably doesn't materially increase the amount of code to write. It definitely does increases the testing burden a bit. And there's always the hard-to-calculate penalty that comes with any added complexity, that affects even just thinking about the application. Still, smells like a win to me! ;-) So, I hope we do take a shot at it for 1.0. But if we really can't, then that's okay, and let's try to get it in at some point further down the road. Cheers, -- Mason --- A ROUGH SYNOPSIS OF THE THREAD SO FAR --- - Should we have one main window or many? - Well let's just have one, that's simpler. - Yeah let's just have one but then we need tabs to do a bunch of stuff at once. - Let's just have one, I don't see much value in multiple viewers, though we obviously need multiple windows of other types. - I can imaging some value of multiple viewers in corner cases but simple is good, let's have only one. - Yeah man, one window is enough. Yeah! Right on, +1. More than one window would be confusing. Etc. - What, Mail.app can open multiple viewers? Cool! - something tab mumble mumble tangent - Well it is actually pretty useful sometimes to have two viewers side by side, IMO - Yeah, multiple, after all these windows are just views into a DB (of my mail) - Yeah Mail does this and it never gets in the way, because its very explicit to create multiple - tabbity tab tab tabs. huh, tabs? yah tabs. no tabs. i hate tabs. tabs are awesome - multiple otherwise can't compare threads/conversations like mail can - hey, what about this combo idea? yah how about this one? is there some kind of 'none of the above' answer? - Well, I personally use multiple to compare conversations and its useful. This aspect of Mail is good. - yah and multi works great with spaces to separate mail 'sessions' - multiple! mail needs it unklike nnw - command-` ftw bro - it's valuable when the main window *is* the app, and there's no ambiguity, even though mail isn't too confusing or anything - OMG OMG if you don't allow multiple mail perspectives view fully capable viewer type windows my head will explode! nooooo - why you need multi windows man - cuz its really powerful when you can set up different perspectives on your mail and see them side by side simultaneously and easily switch between them; mail use has lots of different contexts; its really powerful bro, honest - dude multi windows sucks, it's sloppy, blech - no, one-at-a-time viewer too limiting - yah ok, and also imo why not? i mean, no good reason *not* to implement multi - wait wait, how about a compromise where you can open new windows, but not with source list? just message list and reader pain - no no no noooooo thats too limiting, see you really need all four components (source list, search/filter UI, message list, and message pane) to really be able to organically create a complete perspective of your email, and I write long emails sorry about that - hmm, yes, after using Mail this way I have started to agree: multi - yah, i think lots of ppl didn't know about multiple viewers in mail - OMG OMG simultaneous mail perspectives are really useful guys, try my example - dude you could totally use smart folders for that - hmm, I am becoming convinced we should do multi. user not forced to use it if don't want. - yah i agree! - no, 1! - really? or do you mean YOU want only 1, but multi users can have their cake too if they don't get their crumbs all over your main window? - +1 multi! i like side by side comparing, but we should make it hard to do by accident - no, iTunes 1 window ftw - i love mailsmith! - can't we all just get along? how about these non-window solutions - don't hate on windows, they're awesome - hey wow, this multi viewer feature is cool - yah! glad to know about this! my Mail.app life is now better - well lets talk some more about partly-functional windows that don't have src list but have the other stuff - well some good arguments in favor of multi viewer on this thread - yah, if you don't like it just don't use it, it doesn't really get in the way - mailsmith! - one window! p.s. i am just beginning to read this thread - hey how about this: i don't care one way or the other! nyaner nya - i would not use a mail client that didn't let me create viewers, it would feel crippled - multiple! with source list, but ok why don't you collapse the source list by default for new windows. yah hey that's a good idea. - dude, you pretend there are no drawbacks to allowing multiple windows. but there are. - ok, true, but they are pretty minor drawbacks if we do it right, vs. major functional limitations if we don't do multi - ok, good points have been raised, but do we have to do this for 1.0? - no, but we should do it - it might be hard, multi windows inherently adds some complexity - ok well how about we try to do it, and if it's too hard then lets do it later - but p.s. i doubt it will be too hard, development-wise :) _______________________________________________ [email protected] mailing list List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
