Mori source questions

I'm not so sure.

I do think that in many workflows an attachment metaphor is the way to go. When I'm using Mail.app I often wish that Mail wouldn't automatically inline display content types that it understands -- that is, often I'd like an attached image or PDF to exclusively be displayed as the icon for the attachment and not appear in the content area (maybe there's some way to achieve this behaviour in Mail, but I haven't found it).

So, yes, a straigtforward attachment metaphor is valuable.

However, I know that other workflows will benefit from viewing a non-text entry type in all its glory. One way to limit how far down the slippery slope we fall is to draw a boundary between viewing an editing. Surely if we make no plans to allow editing of non-text types from within Mori then we've cut out much of the complication and problems associated with trying to merge in the many menu options that even a simple image editor would demand.

But you did specifically refer to viewing, not editing, non-text content types as a source of potential problems. While Preview will always be better at viewing PDFs and Safari always better at viewing web pages, I propose that there is still real value in viewing these types within Mori. Let's take an example with another application: NetNewsWire.

When I'm in NNW I have a similar multi-pane user interface and the content being displayed is either going to be a melange of text and images, or sometimes a full blown web page if the feed contains lots of high-fidelity HTML or if I double-click to view the feed's originating web page. Most of the time I am totally comfortable with this experience in NNW and don't worry that it doesn't give me the same experience or power as Safari when viewing HTML content. When I'm feeling like I want more, I simply ask NNW to view the content in Safari instead of within NNW. I'm personally comfortable with this.

So, I think we're in the same ballpark -- I think I'm happy with a Preview, but of the full-size variety rather than a thumbnail. Would we still call that a preview experience or a viewing experience? Not sure, but I think the range of operations on the content are just to view and anything more is a trip out to the content's native application.

I think that without this sort of functionality people will resort to dropping their nont-text content into the NSTextView and hope for the best (which may turn up its own set of issues).

Gavin.

I'm surprised to read this direction change (RTFD only), or rather a staying the course from HBN. I had thought the Tiger WebKit made the logical new choice, and made the various formats all relatively transparent ... it handles RTF, HTML, images, pdf etc etc etc. The big challenge GUI wise would be smoothly handling the differences between a read/write RTF(D) note from an HTML note sporting read with a separate read/write HTML source from an image or pdf which might be read only. That would be awkward, but I'm sure there's a nice elegant solution.

But the problem I have with attachments vs. notes is that it removes non-text notes from the outline which limits certain types of workflow. Imagine that we had a link node type and lets say there were operations that one could do with that. Lets assign a rule to the hierachical organization, say all link nodes on the same level appear as tabs in Safari, and all link nodes on different levels appear in separate instances of a Safari window. By applying Safari to an entire "directory" tree it could pop n-windows each with m tabs ... all at once.

That's just one example, but you could imagine many more.

Then there's the issue of efficiency. Right now if I drop an image on an RTF node, it's for all intensive purposes inaccessable outside that node. What if I wanted to drop an image header on 100 nodes. Currently that's 100 copies of that same image. Not exactly ideal. If it were revealed, and part of the hierarchy then I could do things like alias it etc. Conversely I could change the header on 100 nodes just by replacing that image. Or I could edit that image in 100 nodes by launching Photoshop on that image and editing it. I don't want an image node because I want to view an image by itself, I want an image node because I want it part of a larger Mori "document" structure.

And finally there's marketshare. Who can say for sure, but the market for a rtf only notebook feels just plain smaller than a notebook which can handle rtf + html or rtf + images or rtf + xxx.

Of course, this is your call, and your vision of what Mori should be and I'll be happy using Mori either way. But man, there's a lot of cool stuff you're dropping here.