On the Issue of Bloatware

I get your interpretation of bloatware to refer to the processing capability of the user. Indeed, I’m not arguing that Scrivener emulate MS Word. That would be silly. And would be a headache to use.

But I’m wondering if there could be two modes. (1) a simple mode with minimum features, distractions and the like and (2) an advanced mode with all the bells and whistles, so that we don’t ever have to use any other app for any of our particular writing needs.

This is a simplification I guess, but sometimes this whole ‘let’s make an app that’s as bloat-free as possible’ attitude kinda gets in the way of innovation.

Ah, Yosimiti, you do like to stir the soup! One of the major issues of bloatware is management of complexity-- not by computers, which merely do as they’re told, but by developers. Keith is one person. If he tried to add every feature anyone ever asked for, he would quickly be bogged down in development of features. This would probably be to the detriment of Scrivener’s stability.

During iOS beta, Keith was pushed hard to include some features–by me, and by others. 99.9% of the time he pushed back harder, only adding something if he felt it would really add to iOS Scrivener’s utility and would not jeopardize release date. I was not upset, though I disagreed with some of his calls. Someone on a development team has to be the one to say no – or the project release gets pushed back. Either that or the project goes out buggy. With Mac / iOS Scrivener, that someone is Keith (because it’s just him), and he does a wizard job of it.

It’s all too easy for a solo developer to give in to the siren call of “just one more feature,” especially if users on forums and social media are vocal about it. One sad case is the iOS soft keyboard Nintype. Its developer never met a feature he didn’t like. He always puts “improved stability” in his release notes, but it never is because he’s added yet another feature that’s introduced new bugs. It does some things that NO other iOS keyboard does – things I really like – but I’ve given up on it because of bugginess and having to turn off the latest useless feature after every release.

I don’t want Scrivener to be like that. So hurrah Keith for sticking to his vision.

What you propose is actually two separate apps. That requires resources (aka money). And it adds complexity for users. Generally all these are considered “bad”.

A few of us have been in the rodeo a long time. simple, purpose built apps perform tasks better from both a user and business perspective. If one finds that the simple, purpose built apps does not meet their expectations… I’m sure there is a different app that will.

That’s just a view that seems to work for many many folks. I wish more developers thought that way (then I’d spend less of my day chasing memory leaks!!).

Screenwriting mode – doesn’t bother me. It never gets in my way. As a good extra should, it doesn’t intrude if not needed.

Compile – the interface is awkward. It almost feels as if it should be a separate app. I hope this will be addressed in v 3. But it’s what lets Scrivener be a “compose once – output to many” system which is one of its major appeals for me.

OTOH, I agree with you about styles. Completely. It will delude yet more noobs (like myself at one time) into thinking that you MUST do formatting while composing. IMHO, Scrivener is best used with minimum formatting while composing, and maximum formatting in compile – and this should be far more clear both in documentation and in interface.

Moore’s Law is acknowledged to have waned, not least of all by Moore himself. On the other side, there’s Wirth’s Law (restated as Page’s Law) which says that software will slow down faster than hardware will speed up.

The issue of usability has already been mentioned, but there’s also the issue of support. Every feature added to an application not only has to be coded, compiled, and tested, but supported after release. Support includes bughunting as well as “customer service,” which runs the gamut from fielding catastrophic technical problems to responding to those of us who feel the need to opine, whine or simply say hello.

There are sound philosophical reasons for software companies to fight bloat and/or feature creep, but there’s also an overwhelmingly practical reason. Each additional feature increases a development company’s workload, and at present strength L&L simply doesn’t have enough people to develop and support bloat, even if they wanted to.

I always thought I wouldn’t be interested in word-processor like styles for exactly the same reason as you, but have now come round. For two reasons:

1. As I understand it, styles will be project-based rather than app-based. In other words, the projects I share with my Windows-using Chinese collaborator can all be based on Times New Roman—the safest exchange font—while my personal projects can have their styles based on Adobe Garamond Pro, my own favourite font. I have more or less achieved that with presets without having to have double the number of presets, but I’m not that comfortable with it.

2. My current use of presets is not to try to produce a page-layoutish output; that I do using Nisus Writer Pro when I’ve finished the draft. To make that straightforward, different paragraph styles are marked by slight variations in colour. When the RTF is opened in NWP, I run a macro over it which finds all the paragraphs in each of the colours and applies the appropriate paragraph style from a style-sheet. Currently, with the preset system, I have to go through every paragraph, checking that it is in the right colour for the macro to work and that is a bit of a pain. With the forthcoming styles, every paragraph in a given style will be marked with the appropriate colour; and if I find I need to change my colour combinations for any reason, or the font—both of which happen from time to time—I will be able to change the style and it will be applied to every paragraph marked with that style.

So, I’m looking forward to the arrival of styles. (A little voice in what passes for my brain tells me that one of the pearls of wisdom that Keith let drop at some point, is that the details of the styles will be applied at compile time … presumably therefore the paragraphs in the editor will merely somehow be tagged internally. I may well of course dreamt all that up.)

Mark

Yes Silverdragon, I do enjoy stirring the soup. Sometimes. But I promise to respect everyone’s ideas, and really, I’m more interested in what others think on the subject of bloatware ultimately.

I guess, all of this, comes out my purchasing history, the likes of which I will share…

I actually bought a Macbook some years back because of two reasons (1) my windows machines was plagued with malware, viruses and woefully slow – it was a Pentium II for those who remember such machines – and (2) at the time Scrivener for Windows or Scrivener for Linux hadn’t been developed, and I was in desperate need of good, cheaper-than-MS-Word- bloat-free writing software, that didn’t slow my computer down. Hence, I forked a few grand for Macbook Pro, bought Scrivener and for several years was quite happy.

These days, I’m currently debating about getting a new computer, but now I have a lot more options. Computers are more than fast enough to run any writing software no matter how complicated, and the size of apps doesn’t matter because HD space is in the terabytes in most new machines; and it occurred to me, that my attitude to search for bloat-free software needed a facelift. Should I even care for bloat? People might rant that there are too many options in MS Word, that it’s too confusing, etc. And this might be why I should continue to use Scrivener, so on and so forth. But I don’t know. It ain’t rocket science, and even the most complicated software, can be learned with time.

This is not to say, that I’m not going to continue with Scriv – I am. It’s just that the whole ‘bloat-free’ attitude just doesn’t seem so strong an argument, as it once was. Complexity isn’t bad. It’s frustrating, yes. But it does have its benefits. And this whole ‘using one app for this’ and another ‘app for that’ attitude seems unnecessarily finicky. There are times where I just wish I had one app for everything, the lazy arse writer that I am.

Feel free to butt-heads guys. Just want to know your thoughts. =)

I didn’t mean to imply that stirring the soup is a bad thing…

Actually, I am a rocket scientist, My undergraduate degree was in aerospace engineering, and I put in a few years on the space shuttle before switching to software development and QA.

If you can keep all the capabilities of even a less-bloated-than-Word piece of software such as Scrivener in your head, my hat is off to you. I can’t. I keep the manual open in Preview in the background while I’m working. No matter how current I am, there’s always something I want to do that I know can be done, that I did about two years ago, and can’t quite remember how to do. And I don’t even touch screenwriting or section numbering or MMD output or …

So. Scrivener is about at my limit for one chunk of software. I honestly consider that separating the compiler might be a good idea. I must respectfully disagree with the concept that more features in Scriv would be a Good Thing.

BTW, the way rocket scientists keep track of all that complexity is lots of eyes on the design, testing and testing and testing, thousands of checklists and sign-offs, and prayer. Even then, sometimes the damned vehicle explodes.

Word is there whenever you want it. So is Office.

The fundamental idea of ‘office productivity suites’ is exactly what you describe: a single application (or group of applications) that does everything any user could ever want.

And yet, somehow, applications like Scrivener continue to exist. Maybe designing usable software is a little more complicated than just piling hundreds of features on top of each other?

Katherine

Absolutely. Amen.

First I laughed. Then I cried. Then I called a team meeting. They all asked “who is this silverdragon and where did you meet them?” Apparently they all like the new team philosophy.

Bloatware tend to become like a Swiss army knife. You can do almost anything with it, because it got all kinds of tools, anything you can think of. And still, no real craftsman ever uses one. They all use specialized tools, designed for exactly the task at hand.

If you hired someone to do work in your home, would you be relieved or worried if the only tool was a Swiss army knife? “This is a guy who really know his trade…”

emphasis mine…

I think this is the core of the issue. Those of us who are hobbiest pollute the craftsman pool to the point that the craftsmen can be hard to find and even harder to hear over the tumult of hobbiest voices.

Another difference is that craftsmen don’t mind if the good tools are a bit expensive, because they are worth it, in the longer perspective, whereas the hobbyist wants something cheap that looks like the real thing, because they don’t really use it that much.

I’m still fairly new with Compile but I like that it’s integrated and not separate. I’m curious as to how you think the documentation could be clearer concerning Compile. (Honestly curious. I’m not disagreeing to disagree.) From the Mac manual, Quick Tour, chap. 5.6 –

literatureandlatte.com/docum … pdf#page44

On the website under the heading Write, structure, revise –

literatureandlatte.com/scrivener.php

In apps like VLC, there are two modes. Simple, and complex. I’m wondering if the future of Scrivener will be headed this way.

Taking into account the wisdom in most of the above posts, I’m going to take a wild happy guess and say - no, not never ever.

… and adding to Dr Dog’s reply, going that way would be like adding a folding screwdriver to a saw…

But what happens when Scrivener gets to the point where, because of its ‘bloat-free’ design philosophy, there no longer becomes any supposed ‘need’ to add any more? I guess my fears straddle in the fact over whether bloat-free-ism ultimately leads to the stagnation of innovation; to the woebegone tenor of complacency; this is something that, I have certain reservations for, from all that people have been saying.

One thought I had was to make Scrivener have the power for users to create extensions for it much in the same way Google extensions or Safari extensions work…I haven’t the faintest idea how this would work, but I think it would be one way to keep the flow of innovation, without making sacrifices to the bloatedness of the source product.

Why would you possibly want to do this? If you add extensions, you add all kinds of possibilities for new bugs, security issues, incompatibilities every time scrivener or the OS gets upgraded, and the likelihood that your workflow will become dependent on an extension that the developer abandons. The market will be tiny and there will be little opportunity for monetization and little incentive to keep code updated.