On 1/25/10 3:57 PM, "Caio Chassot" <[email protected]> wrote:
>> 1) Stop thinking about IMAP as if it were some cohesive standard with a >> consistent implementation. > > Yes. Major suck. Yet you go on and on about supporting advanced IMAP features > later. I think the way to deliver a consistent experience and eventually ship > is to focus on the basics of IMAP, and do most things on the client. Define "basics". That's really hard with IMAP. > > > >> 2) Regardless of who this project is aimed at, people using it are going to >> get email from "icky" sources, like Outlook users who have no control over >> their email format. ... > > Man, your real world sucks. TNEF eh. Can I say, plugin? I have that now. If that's the answer, Letters loses to inertia. > > I mean, we'd really love to support all kinds of shit other MUAs throw at us, > but you know, programmers writing the code, programmers generally don't get > TNEF email. Again, if this is only for programmers, I can start ignoring the entire thing now and forever. Power User is not another word for programmer, and, there are programmers on Macs who work in a corporate world, or with people who work in a corporate world. Really. > > Priorities and all. I'm sure that if a good implementation shows up, plugin or > not, it'll ship by default. > > (There's some GPL shit to handle this, so a plugin could rely on it. It just > wouldn't ship by default.) Again, if everything is a plugin, then: 1) Great. Now when it breaks, whose fault is it? The application? The Plugin? Who has to fix it? 2) if everything is handled by plugins, well, we kind of have that now via external applications. Why would anyone switch to letters if they have to spend real time dinking around with this plugin vs. that plugin? >> 4) Get copies of all the Mac IMAP clients and spend some time with them. > > We're doing the next, more viable thing, which is talking on this list and > letting people share their whoas and woes with past clients. There's a real difference between someone who isn't writing code doing that and the people who ARE writing code doing that. >> 7) AppleScript is a must. > > I agreewith a lot of painfor the exact reasons you mention. I'm just > personally staying away from it and doing everything on the shell. That's a great option. But if you live above the shell, shell doesn't work real well. >> 10) Everything can handle a correct message. Some attention to "how will >> this handle mangled crap" is important. > > I, for one, would love to get my hands on a useful corpus of craptastic mail. I imagine the T-bird folks on this list might be of some help here. >> 3) They have to be able to talk to the Address Book and iCal frameworks. > > It's part of being a Mac app. Unfortunately, too many applications, (Mozilla foundation!) would disagree. > > >> 4) Three-pane has to be an option. It doesn't have to be the default, but it >> has to be available. People are trained to expect that. I'd recommend >> 'borrowing' E'rage's vertical take on the three-pane view as an option, if >> you have a larger screen it's pretty tight. > > You mean mail-lame-3-pane? I've been pushing for NNW-widescreen, aka 3-column. > The design effort on dev has gone that direction too. (I haven't fully caught > up with the thread, maybe it diverged?) > > Again, I think 3-pane is a legacy of 4:3 screens. Um, it's not lame if you've been using it for over a decade. As well, three column has limitations, and not all screens are wide. >> 10) Plugins with a well-documented architecture, yes. Plugins with "here's >> some source, that's all you need", no. > > The inevitable is we'll start with the latter to derive the former. As said > earlier, implementing crucial application features as plugins should ensure we > actually arrive there. Bad idea. Letting documentation wait until "it's done, we'll do it later" sucks. Or do you really like it when Apple documentation lags public framework releases by large amounts of time. Documentation is not a one-off thing, it actually takes real skill, regardless of what "Dilbert" wants us to think. >> 11) Documentation. It's still important. > > Especially developer documentation, at this stage. Certainly end user later, > as the idea is to offer an extensible client, and nothing sucks more than > figuring out an alien system. A lot of people have volunteered. Let's hope > they're still around by the time doc efforts can begin. Um...again, no, they kind of have to proceed together. Otherwise, it gets dumped into the "Later" bin which always translates to "Not me man" >> 1) Given the stupidity of mail retention rules, (don't get me started on >> this), the ability to not use any local storage at all would be nice. > > Yeah I don't know about it. The original discussion about the backend > implementation is that we'd cache everything. There's been a vocal minority > that just wants everything on the server, nothing local. > > It may be doable because you inevitably have to talk to the server at some > point, but I don't think it'll be truly optimized for. (I mean, basic headers > first, messages later, attachments much later, yes. More than that, don't > think so.) Do both. It widens your audience rather a lot. > > >> 2) This is an actual IMAP thing, but rarely used: The ability to publish or >> subscribe to folders, and the ability to unsubscribe to folders in your own >> store you don't care about. > > Account-local un/subscriptions have been considered and I don't think they'd > be much trouble to support. Although if the source list is customizable, why > do you care what you're subscribed to or not? Because there's a difference between not seeing a folder and not talking to it at all. > > I guess there's some IMAP extension that lets you get notifications for all > your subscriptions at once, instead of a single mailbox? That would justify > giving it attention. > > As for publishing, totally 2.0. Can you make a good case for it? As a really edge-case IMAP user, definitely. In fact, it's one of the bigger reasons cited for things like outlook. They use a different name: Public Folders. For collaboration, the ability to have a mail folder, or many folders that people can publish, and or subscribe to is not minor. Yes, I know Google Wave. The problem is, stuff like Wave requires you to pretty much replace email with their client. For an email client, IMAP subscriptions are the way to go, since most servers, (well, not Google's but theirs sucks anyway) support it. Unfortunately, it's one of those things you have to use to really get. >> 3) A good UI for server-side functionality, esp. searching. Actually, when >> searching online folders, doing it on the server as the default when online >> would not suck. > > Been there earlier. The consistent thing is to handle stuff on the client. Let > plugins handle specific servers/server features. The kind of search we want to > implement is beyond any server's capabilities. Server side searching and the like is not some random feature. It's rather one of the core bits of IMAP, the idea being you offload things that can be handled by the server onto the server. Even the less-good servers, (that aren't Gmail) deal with this, and if you're aiming this at IMAP power users at all, it's kind of expected. > Sounds like something nice that I would never use. Hopefully can be handled by > a 3rd party plugin. You evil IT needs are heard, but indies, you know, are > indies for a reason. Again, if the sole purpose of this application is to make Indie devs happy and everyone else can funk off and write plugins, someone say so, and I'll make sure that all my non-Indie dev compatriots ignore this project. If Letters is going to be a programmer-only toy, then someone grow a pair and state it clearly, or let's stop pretending that only programmers are power users. >> 6) I could care less about external editors, and actually hate the concept. > > Then you don't use them. > > (And I wouldn't mind hard-coding against Word.) External editors are not a core feature of an email client. Why not shovel all that silliness to a plugin? > > >> 7) Power User != Programmer, Power User != Programmer, Power User != >> Programmer, Power User != Programmer, Power User != Programmer, Power User >> != Programmer, Power User != Programmer. There, point made. > > Yet, you'd be not surprised at all to hear that programmers are writing the > code. By that logic, all applications should be only for programmers and if you can't program, don't use computers. > > Not evil programmers who hate the power user, mind you. But still, your point > might not make all the way across. Again, if this application is only for indie devs, say so now, so the rest of us stop wasting our time caring about it, and can go talk to people who care about someone who is an email power user, yet is not a programmer by trade. -- John C. Welch Writer/Analyst Bynkii.com Mac and other opinions [email protected] _______________________________________________ [email protected] mailing list List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
