selecting non-contiguous text

For all things Mellel

Moderators: Eyal Redler, redlers, Ori Redler

staypuffinpc
Got the styles thing figured out
Posts: 12
Joined: Tue Sep 11, 2007 7:25 pm

selecting non-contiguous text

Post by staypuffinpc »

Is there a way to select non-contiguous text in Mellel? I want to make changes to several portions of a page at once, but they're not right by each other. In every other program I own, I can hold down the command key to make non-contiguous selections. Why won't this work in Mellel? More importantly, is there a way to do it that I'm unaware of?
rpcameron
Knows everything, can prove it
Posts: 980
Joined: Wed Oct 26, 2005 12:48 am
Location: IE, CA, USA

Re: selecting non-contiguous text

Post by rpcameron »

Mellel uses a different text system than OS X, and therefore does not have some of the features that come with OS X's native text system (such as non-continguous selection, and 10.6's new text substitutions). The trade-off, however, is better OpenType support and true RTL support.
— Robert Cameron
staypuffinpc
Got the styles thing figured out
Posts: 12
Joined: Tue Sep 11, 2007 7:25 pm

Re: selecting non-contiguous text

Post by staypuffinpc »

for most people, I don't believe that's really a good trade off. It makes for a clunky system to work with, especially since it's a feature that's been part of the system for well over a decade. I would encourage the developers to figure out a way to make it happen.

As an extension to this thought, there are some things I love about Mellel, which is why it is my main word processor for first drafts. But silly oversights like no contiguous selection, the fact that one's undo list is erased when saving a document, and no integrated help really make it awkward to work with. I think the whole thing could use an HCI expert to overhaul the GUI and make the whole experience more amicable.
rpcameron
Knows everything, can prove it
Posts: 980
Joined: Wed Oct 26, 2005 12:48 am
Location: IE, CA, USA

Re: selecting non-contiguous text

Post by rpcameron »

staypuffinpc wrote:It makes for a clunky system to work with, especially since it's a feature that's been part of the system for well over a decade.
Actually, non-contiguous text selection was only introduced in Tiger (10.4) which was released in Q2 2005. Text substitution was introduced with Snow Leopard (10.6) in Q3 2009. I don't recall if MacOS prior to OS X supported non-contiguous selections system-wide, but I know that Nisus Writer Classic certainly did; text substitution was only available through third-party applications.

If RTL support and OpenType features are important features, then Mellel is definitely the way to go; however, I would not say that the program is for everyone, nor does it claim to be. The only two software packages that compete with Mellel's typography are Adobe's Creative Suite (best OT support) and XeTeX.
staypuffinpc wrote:As an extension to this thought, there are some things I love about Mellel, which is why it is my main word processor for first drafts. But silly oversights like no contiguous selection, the fact that one's undo list is erased when saving a document, and no integrated help really make it awkward to work with. I think the whole thing could use an HCI expert to overhaul the GUI and make the whole experience more amicable.
I completely agree that Mellel's interface could use an overhaul. It is dated, awkward, and looks out of place on a modern OS X system. However, non-contiguous selection is anything but a "silly oversight"—it is actually quite difficult to implement in software. Better undo support would be nice, and perhaps "integrated help" would be nice, but Mellel's manual is quite extensive, and the user-produced tutorials cover most every other aspect.
— Robert Cameron
staypuffinpc
Got the styles thing figured out
Posts: 12
Joined: Tue Sep 11, 2007 7:25 pm

Re: selecting non-contiguous text

Post by staypuffinpc »

Patrick,
Thanks for your informative replies. You say that non-contiguous text selection was only introduced in os 10.4, but that seems off to me. I've been using Mac since its Classic days. Perhaps there was no system-wide 'hook' for such selections for developers, but non-contiguous selection has long been a core part of the system. I've been able to select non-contiguous files in the Finder for years. MS Word has also had it available in their Mac products for as long as I can remember. Where this selection thing becomes especially annoying is in working with tables, which is still terribly awkward in Mellel.

I know you mention that Mellel is for a select group of people that need certain text support, but I certainly hope the developer has a much less myopic view of his product than that. Quite frankly, I don't need it for that feature. The reason I use it is because, klunky though it may be, Mellel has figured out how to manage working with long docs better than other word processors. Again, though klunky, their use of styles is accurate (MS Word screws this one up like crazy. Apple Pages actually gets it right and has a MUCH better interface for working with styles, but I can't create 'sets' or carry them over between documents. Apple also hasn't catered to the longer document crowd).

Not integrating the Help manual with the system is also silly, IMO. Mellel purports to be Mac, but is ignoring key features of Cocoa apps. At one time, a manual may have been appropriate, but no longer. It's time to better integrate system components, even if it is difficult (and I don't see why selecting non-contiguous text would be so hard. Couldn't an array of text coordinates be started every time a selection is made? using the option key would add to the array instead of replacing it. Conceptually, it's not that difficult).
DylanMuir
Knows everything, can prove it
Posts: 248
Joined: Tue Jan 30, 2007 11:31 am
Location: Institute of Neuroinformatics, Zürich

Re: selecting non-contiguous text

Post by DylanMuir »

I have to say, I have never used non-contiguous text selection in my life, had no idea it even existed in word or any other editor or word processor, and don't really see any great use for it.

In a spreadsheet it makes much more sense to me.

DRM
rpcameron
Knows everything, can prove it
Posts: 980
Joined: Wed Oct 26, 2005 12:48 am
Location: IE, CA, USA

Re: selecting non-contiguous text

Post by rpcameron »

staypuffinpc wrote:You say that non-contiguous text selection was only introduced in os 10.4, but that seems off to me. I've been using Mac since its Classic days. Perhaps there was no system-wide 'hook' for such selections for developers, but non-contiguous selection has long been a core part of the system. I've been able to select non-contiguous files in the Finder for years. MS Word has also had it available in their Mac products for as long as I can remember. Where this selection thing becomes especially annoying is in working with tables, which is still terribly awkward in Mellel.
I think we are on slightly different areas of thinking here. Non-continguous selection of items in the Finder (and file dialogs, lists, &c.) has always been present. (Well, maybe not always, but as far back as I can remember, including System 6.5 and Windows 2.0.) However, non-continguous selection of text is a different beast. It really was 10.4 when system–wide non-continguous text selection became available.

(Perhaps at this point I should be more specific. Non-continguous and rectangular selection of text was made available to the NSTextEdit control—and by extension to the controls that inherit from it. Therefore, most any place where a user would be entering multi-line text was instantly able to select non-continguous portions of text once they upgraded to 10.4 or beyond. However, Mellel does not get this functionality for free, because Mellel's text areas are not based on NSTextEdit. You will also notice some things that Mellel's text areas cannot do as well, such as Emacs keybindings, or access to the Dictionary panel; again this is because Mellel does not use the system's text engine.

Of course, the reason for Mellel's "reinventing of the wheel" is quite functional. When Mellel was introduced OS X had pitiful-to-no support for RTL scripts. This was essentially Mellel's raison d'être, as it was geared towards Semitic and RTL word processing, definitely a niche market. Also, OS X had poor support for OpenType fonts and instead went with its own proprietary AAT. The problem with this was that the majority of fonts used in RTL writing/typography were based on OpenType, which was necessary particularly for Arabic and its contextual letterforms. Both Mellel and OS X have continued to evolve and grow, and while they are both going towards the same goal, they basically had different origins. Personally, I feel that Mellel is filling the void that was left Nisus failed to make a graceful transition to OS X, and Nisus Writer Classic was left as Classic only, and Nisus Writer Pro still does not have the features that Classic did.)
staypuffinpc wrote:I know you mention that Mellel is for a select group of people that need certain text support, but I certainly hope the developer has a much less myopic view of his product than that. Quite frankly, I don't need it for that feature. The reason I use it is because, klunky though it may be, Mellel has figured out how to manage working with long docs better than other word processors. Again, though klunky, their use of styles is accurate (MS Word screws this one up like crazy. Apple Pages actually gets it right and has a MUCH better interface for working with styles, but I can't create 'sets' or carry them over between documents. Apple also hasn't catered to the longer document crowd).
Again, I agree with you here. However, by ignoring and/or disregarding Mellel's heritage or its core base of users, you miss the reason why many use the program. Mellel's superior handling of RTL scripts and catering to those users who need that support is not myopic, as you claim, but its raison d'être. Mellel's handling of styles is indeed superior to Word's, and Pages' is nice. However, Pages' inability to separate character styles from paragraph and list styles makes it almost as bad Word.

Perhaps I am in the minority, but I still have yet to hear a truly compelling argument for why non-continguous text selection is so important. For very disparate streams of text, I would iteratively modify them as I browse through the document. For similar and/or repetitive streams of text I could use Mellel's powerful Find and Replace and Replace Styles. But, maybe I am missing something that could improve my workflow?
staypuffinpc wrote:Not integrating the Help manual with the system is also silly, IMO. Mellel purports to be Mac, but is ignoring key features of Cocoa apps. At one time, a manual may have been appropriate, but no longer. It's time to better integrate system components, even if it is difficult (and I don't see why selecting non-contiguous text would be so hard. Couldn't an array of text coordinates be started every time a selection is made? using the option key would add to the array instead of replacing it. Conceptually, it's not that difficult).
Conceptually it is simple, but as they say, "the devil is in the details". A move such as this requires a great deal of refactoring of the source, and a shift in the way the program's internal structures are created. Perhaps it will make it to a future version, but such a "trivial" feature is most often anything but.

However, I am in absolute agreement that Mellel needs a refresh. Perhaps version 3 could introduce a truly Mac OS X inspired interface. Hopefully it will also bring with better adoption of Mac technologies as well, such as AppleScript dictionaries and Automator workflows.

I'm still up in the air about Mellel's tables. For basic text needs and the display of tabular data (the definition of a table), they are quite suitable and serviceable. However, more advanced layout options would be nice. But, then Mellel begins to enter the realm of page layout, and not just a word processor, and I feel that would be a mistake. It seems that everyone wants the one program to rule them all, and that was exactly the problem with Word. What is wrong with finding the right tool for the job, and using that, instead of having one tool and asking it to work for every job? I'm not trying to start a riot (or hijack a thread), but just posting some points to consider.
— Robert Cameron
nicka
Knows everything, can prove it
Posts: 677
Joined: Thu Oct 20, 2005 2:55 pm
Location: Oslo
Contact:

Re: selecting non-contiguous text

Post by nicka »

On non-contiguous text selection (NCTS) pre 10.4 (including classic Mac OS): I'm pretty sure that this was only possible in a few word processors. Nisus Writer was one. It had NCTS before Word did. I'm not sure when NCTS was introduced into Word, but it certainly wasn't there from the beginning.

Remember that in the classic Mac OS each word processor had its own text engine. Now a few word processors such as Mellel and Word have their own text engines, but most use one that is built into Mac OS X. There are tradeoffs inherent in the choice made by the developers. Apps that use the system provided by the OS get features added for free when the OS is upgraded, but they lose a lot in the developers' ability to implement styles and display of text the way that they (and their users) want it. If proof is needed of that, just see the Nisus or Scrivener forums.
nicka
Knows everything, can prove it
Posts: 677
Joined: Thu Oct 20, 2005 2:55 pm
Location: Oslo
Contact:

Re: selecting non-contiguous text

Post by nicka »

The reason I use it is because, klunky though it may be, Mellel has figured out how to manage working with long docs better than other word processors. Again, though klunky, their use of styles is accurate
A quick follow-up. This is why I use Mellel too (although I don't agree that the styles are klunky). The styles would be a lot more klunky if the developers had chosen to use the text system built in to OS X: see the OS X Nisus Writer whose developers are the only ones I know of to have hacked styles onto the system.
gke
Got the auto-title mojo working
Posts: 23
Joined: Fri Oct 21, 2005 7:21 pm

Re: selecting non-contiguous text

Post by gke »

I feel that Mellel is being done slight injustice here in being described primarily as a niche product for people needing advanced OpenType and RTL functionality. I think its niche is actually much broader - Mellel still is, for example, the only Word processor on the Mac which can hyphenate Russian text, and I guess this goes for a lot of other languages as well. Also, in combination with BookEnds, it is an unbeatable duo for academic writers, which has, again, no analogy in terms of ease and flexibility on the Mac platform.

As for the GUI, I cannot understand why people make such a fuss about this - I could not care less and really wish that the Redlers would devote their apparently scarce programming time to adding and improving functionality rather than looks.
nicka
Knows everything, can prove it
Posts: 677
Joined: Thu Oct 20, 2005 2:55 pm
Location: Oslo
Contact:

Re: selecting non-contiguous text

Post by nicka »

I agree with gke. Mellel is unique on OS X in what it can do, and in being absolutely stable and reliable while doing it. The problems are almost all do to with things that existing and potential users need to do which can't yet be done in Mellel. I really hope that the priority is getting Mellel to the state the Redlers set as an aim some years ago: a long document processor that can replace Framemaker.
One minor caveat: some bits of the user interface need minor attention. The FindSet dialogue is a mess, but a cure is not difficult to see: it would be massively improved just by making it resizable -- really a trivial change to implement. But in spirit I agree. Let's have image captions, export to pdf of table of contents, marginalia, even support for vertical CJK text before any large-scale overhaul of the interface.
staypuffinpc
Got the styles thing figured out
Posts: 12
Joined: Tue Sep 11, 2007 7:25 pm

Re: selecting non-contiguous text

Post by staypuffinpc »

As far as Mellel's heritages is concerned, I certainly agree that it made its way into the market by catering to a base of users that needed better handling of international alphabets and RTL encoding. I don't mean to take away from that at all, and there's a lot to be said for a fiercely loyal user base. However, as far as the "myopic" comment goes, to only cater to a niche market is, by definition, myopic. Interestingly enough, that's what many on here are clamoring for—some seem to not really have the developer's best interests in mind, but rather their own. You're asking to add new features that speak to your specific needs rather than asking the developer to improve his product for a potentially larger market.

For those that can't understand why a GUI is important, let me explain. A specialization of my field is Human-Computer Interaction. The human-user interface experience can make or break people's impression of a system with the exact same functionality. If I have to search for a needle in a haystack to do something that I expect to find at my fingertips, I'm more likely to rate that program poorly. Here's one example from Mellel—background color in a table cell. There is a "color" box one can click on to change the color. It's fully clickable and I can change the color. However, unless the little "background" drop-down has the "Solid" option selected, the color won't take. Why is that box 'active' if the drop-down is set to none? Goodness, why is this even a 2-stop process? It makes more sense to click on the color box and, if I don't want color, to have a "no color" option a la Photoshop/Word/Pages/just about everything else I can think of. Mellel is replete with these little quirks. It taints the user experience and turns off many new users. If there is a "steep learning curve" for a product such as this, you can bet that it's not a functionality issue, but rather an implementation one.

As for integrating the Help. The hooks are there in the system API. It may be that the developer is still using his own framework that years ago was better than the system option. But if the developer is really moving forward with the system, integrating the help is a matter of reformatting his help pages into HTML pages. Is it a lot of work? Not really. Is it tedious? Yeah. Is it worth it? Again, understanding HCI is important here. The Help system was set up to aid people toward solving their problems more quickly. Although one can always access a .pdf version of help, the search options within a .pdf don't compare to a regex search that is normally executed from the help menu. One doesn't have to have the exact words, which is much more friendly and useful than having to guess the exact phrase in a .pdf viewer.
staypuffinpc
Got the styles thing figured out
Posts: 12
Joined: Tue Sep 11, 2007 7:25 pm

Re: selecting non-contiguous text

Post by staypuffinpc »

DylanMuir wrote:I have to say, I have never used non-contiguous text selection in my life, had no idea it even existed in word or any other editor or word processor, and don't really see any great use for it.
DRM
This blows my mind. Here's a use that I could guess you've possibly wanted before but not been able to use b/c it wasn't available: What is one of Mellel's strengths? Correct implementation of styles. Suppose you want to apply a style to several portions of text all at once. It's MUCH easier to select each portion of text non-contiguously (Option + Select) than it is to select each one individually and apply each style individually. If you want to undo the application, it's a single undo, as opposed to the stack you'd create without the option to select non-contiguous text.
DylanMuir
Knows everything, can prove it
Posts: 248
Joined: Tue Jan 30, 2007 11:31 am
Location: Institute of Neuroinformatics, Zürich

Re: selecting non-contiguous text

Post by DylanMuir »

I just don't see the burning need. I apply styles as I go, so I would rarely need to apply a new style to several segments of text. In any case, the long documents I write would require hunting for the text in any case; if the text isn't all on one page, how can I be certain that I still have all the required text segments selected? I would have to hunt back through to double-check that I didn't accidentally de-select everything else. I don't think that would be a great interface, actually.

Your other suggestions — GUI improvements and consistency; integrated help — strike me as much more important. But I would prefer the functionality that I need — smart handling of captions; figure styles; dynamic TOC — introduced before UI niceties.

DRM
gke
Got the auto-title mojo working
Posts: 23
Joined: Fri Oct 21, 2005 7:21 pm

Re: selecting non-contiguous text

Post by gke »

Regarding the niche-market vs general market argument - theoretically, of course, it would be best to aim for as large a market as possible, but in practice that involves catering to the needs of such a wide variety of users that it becomes nearly impossible to implement all the features this would require. The enduring lack of hyphenation support for a wide selection of languages for years on end in all of the established word processors on the Mac platform (Word, Pages) is a strong point in case, and I have no doubt at all that there are countless examples more. This makes a powerful argument, I think, for a development scenario focusing on a particular niche-market. After all, nobody would doubt the validity of concentrating on niche-markets as a business-model in food production anymore, so why would not the same go for application development?
Post Reply