Literature and Latte

Straight from the OED (Oxford English Dictionary Online):

Bloatware:
Software that requires an excessive amount of disk space or memory, typically due to the repeated addition of new features over successive versions.
1991 Businessweek 30 Sept. 100/1 Worse, they'll be stuck with poor applications programs—what he calls ‘bloatware’.
1998 N.Y. Times 3 Dec. d3/5 As long as software developers keep making bloatware, you will need a bigger hard drive.
2011 Lifehacker (Nexis) 2 Feb. I hate syncing with the bloatware that is iTunes.

I think we can all agree that the OED is a tad bit skimpy on the full ramifications of the word's ultimate meaning!

Graybyrd wrote:De-bloat de bloat: nano + markdown => pandoc => ePub. Salt, season, & distribute.
OH! Scrivener? Repository & Reference.

I understand all but the "nano" reference. To what (software?) are you referring? Inquiring minds want to know...

Oh. A Windows editor. Nevermind.

yosimiti wrote:From the urban dictionary:

bloatware

A piece of software, hardware or website that attempts to do too much and becomes utterly useless for users. An example of bloatware would be a word processing application that also tries to be your page layout program, drawing tool, and web browser; absorbing half your hard drive and all your RAM in the process.


Mind you guys, this isn't my definition per se; I'm just putting it out there.

Oh, so emacs?

devinganger wrote:

yosimiti wrote:From the urban dictionary:

bloatware

A piece of software, hardware or website that attempts to do too much and becomes utterly useless for users. An example of bloatware would be a word processing application that also tries to be your page layout program, drawing tool, and web browser; absorbing half your hard drive and all your RAM in the process.


Mind you guys, this isn't my definition per se; I'm just putting it out there.

Oh, so emacs?

ROFL!

Silverdragon wrote:But there is still a widespread misconception, particularly among users of the U------- software, that Scrivener *requires* users to mess with final output format during composition. Having Real Styles will only reinforce this error.

But it *does* require you to mess with formatting after you've composed to an external output format, because Scrivener is not a full-fledged layout program (nor does it claim to be). But with "real styles", that should actually get easier and more straightforward -- the kind of hacks Mark does to get things working nicely with NDP should become easier to achieve with .DOC and .DOCX output, because instead of today's presets just applying one-time formatting to the text in Scrivener, the style information can also be tossed along and matched up to the document template.

This would have been AWESOME for me writing the Exchange Server Cookbook -- having Scrivener pour everything out to a DOC that contained embedded style names that I'd matched to the ORA Word template. I could just take Scrivener's output DOC, attach the template, and have a ready-made document to pass on to the publisher for edits and reviews.

So I'm afraid I don't see how "real styles" are going to make things worse. I see them as potentially reducing (in some cases, by quite a lot) the post-formatting fiddling one has to do by allowing the style information to be part of the output so that the layout program can slurp it in and do the needful. If other people who want to cheerlead for another program and don't understand Scrivener want to think otherwise, well, their ignorance really isn't my problem.

Yeah, this subject is beyond me now. Pleasantly waiting till someone starts speaking English again.

devinganger wrote:
Oh, so emacs?

I love playing with emacs. I do it every year for about 2 months. I start with it, because I prefer writing in vim, but orgmode, so I use vim in emacs, and for a while it's brilliantly simple, efficient and effective, and then I start thinking about interacting with DTPO and Tinderbox and I have fun setting it all up and then...

... I realise I've had two months of great fun messing around learning and configuring the software and not really working, and that the small bits of friction that comes from getting emacs to link to the other programs add up to more irritation over the course of a week than just using the not-very-good OSX text input in the first place. So I go back to standard OSX.

This could all be avoided if we had vim-bindings in Scrivener.

Pretty please?

brookter wrote:

devinganger wrote:
Oh, so emacs?

I love playing with emacs. I do it every year for about 2 months. I start with it, because I prefer writing in vim, but orgmode, so I use vim in emacs, and for a while it's brilliantly simple, efficient and effective, and then I start thinking about interacting with DTPO and Tinderbox and I have fun setting it all up and then...

... I realise I've had two months of great fun messing around learning and configuring the software and not really working, and that the small bits of friction that comes from getting emacs to link to the other programs add up to more irritation over the course of a week than just using the not-very-good OSX text input in the first place. So I go back to standard OSX.

This could all be avoided if we had vim-bindings in Scrivener.

Pretty please?

That would be nice, yes, although for me it would involve a (re)learning curve I've found myself longing for the "open in external editor" option so temptingly available in the Research folder-- then Scrivener could just hand off the file and not have to turn itself inside out with various editor bindings...

yosimiti wrote:Yeah, this subject is beyond me now. Pleasantly waiting till someone starts speaking English again.

Sorry the conversation has devolved into UNIX. But when you mention bloatware, alas, you invite us techno geeks in and emacs is a bloated UNIX editor-- or was, at one time, an editor...

Back to the subject of bloat,

nontroppo wrote:Bloat in software is incredibly relative to the user...

There are a few objective measures of bloat, and for me that comes back to the ability of the developer(s) to maintain the system. I may be offended by the presence of a feature I don't use even if it never gets in my way. That's subjective. If the mere presence of multiple features causes an out-of-memory crash in a generously provisioned system, that's bloat. If the developers can't keep up with the maintenance queue, and bugs get more numerous rather than fewer, that's bloat. If my favourite feature gets deleted in removing bloat, I may be disappointed. Oh, well.

And remember, last decade's bloat is today's lean app.

nontroppo wrote:Even though I use MMD for all my writing (thus don’t fuss with styling my text for output at all), I neverthless think a better Styles system is going to be a super useful update for many Scrivener users.

Wait until you see what the system will be capable of doing for MMD and other various forms of plain-text writing. They needn’t in fact have anything to do with the formatting of text, in or beyond the editor. As with many features in Scrivener, multipurpose functions are a way of doing more with less bloat (to stay on topic).

Granted most people will use them to make their font different or whatever, and maybe that will tempt some people into just reverting back into old WYSIWYG working habits, I don’t know—but functionally we’ve always had a very similar system in Presets. At least in terms of the UI inviting one to use them “incorrectly”. For example default presets ship with title and heading formats among them—in a writing system that turns your outline into functional document structure. I don’t think calling the feature something else but basically presenting it in an identical fashion on the surface will make a huge difference in “mis-”usage of the software.

devinganger wrote:So I’m afraid I don’t see how “real styles” are going to make things worse. I see them as potentially reducing (in some cases, by quite a lot) the post-formatting fiddling one has to do

Styles for me will replace a labyrinth of regular expression-based Replacements, some post-compile scripting and other downright hacks of the feature set (like using inline annotations for syntax injection instead of… comments). It might be a new feature, and thus one more tick in the toward-bloatness quotient of the software, but in terms of usage, the workflow itself is less bloated, and isn’t that what really matters?

AmberV wrote:...Styles for me will replace a labyrinth of regular expression-based Replacements, some post-compile scripting and other downright hacks of the feature set (like using inline annotations for syntax injection instead of… comments). It might be a new feature, and thus one more tick in the toward-bloatness quotient of the software, but in terms of usage, the workflow itself is less bloated, and isn’t that what really matters?

Inline annotations for syntax injection . . . why didn't I think of that?

Silverdragon wrote: And remember, last decade's bloat is today's lean app.

I'm wondering, philosophically speaking of course, could one argue that bloat, due to its relative nature, isn't... really... any...thing...?

yosimiti wrote:

Silverdragon wrote: And remember, last decade's bloat is today's lean app.

I'm wondering, philosophically speaking of course, could one argue that bloat, due to its relative nature, isn't... really... any...thing...?

Nah, it's a pejorative term for software that annoys the speaker by its large and increasing feature set, or in my case, perceived level of bugginess that doesn't get smaller while the feature set gets larger. As such, it's no more precise than than any other such term. When L&L say they want to avoid bloat, I suspect it's that they're avoiding including every user request as rightly they should to keep their product design focused to what they want to sell and support...

I mean, no one wants to try to make a living off OpenOffice...

So bloat-free is a euphemism for 'we don't listen to everyone'?