Scaling selection

How about scaling a selection?

Usage scenario: I made a complex diagram. I still want to keep it around, but I don’t want it to take up as much space on the board-- I have ‘bigger’ fish to fry. But before moving onto bigger fish, first I have to make this one smaller.

Desired behavior: Drag a selection box to select 20-30+ objects (text boxes and connecting lines, maybe a background shape) and drag at the corner (possibly with a modifier key) to scale all the elements down (also scaling fonts, and preserving relative positioning). In the future, select the same elements and scale up.

How does this fit into the development scheme? I think this could be a very cool feature.


Would it not be just as convenient to drag the cluster off to the side, or maybe start a new board and link to the current one in a note within it?

A tip for “making space”, add a new note anywhere and then select everything but that note (Cmd-A and then Cmd-click on the anchor note), zoom out as far as you want, and drag everything to the right/down. Now you can return to the area where you left the anchor note and restore the zoom. This is just a trick for expanding the board to a large degree all at once, rather than gradually as you add notes.

Well, I guess that for my workstyle, no, it wouldn’t be more convenient, because scaling is another way of showing data subordination/change of focus, and it’s also a way of preserving the spatial layout of elements on-screen but making it possible to fit more information in the existing location. This difficulty scaling/hiding-revealing data makes it so I have to repeatedly reshuffle the spatial layout to fit everything as a design is developing-- the easy way to make something visually smaller is to move it out of the way, which breaks the 10 or 15 or whatever connection links with other items, or hides the lines behind the other items. It’s a hassle. Scaling something in place makes the changes with the connecting lines less of an issue, since it’s mostly going to where it already is.

I like Scapple because of its spatio-visual and non-hiercharchical nature-- things exist in a visual two-dimensional space (rather than in a long list or some other linearized format), and you aren’t forced into hiercharchies (as with ‘mind mapping’ and outlining software). However, sometimes hierarchy is needed, and one way to create hierarchy (whether temporarily in a workspace, or long-term in formatting a document) is through scale-- how much space something takes up in a composition.

Scapple allows for manual type scaling, but the spatial relationships and connecting lines will break down. I like the behavior of something like Adobe Illustrator with ‘scale fonts’ turned on-- you can select a number of objects and drag the corner of the bounding box, and everything scales up. (As I’ve already said, I understand that scapple strokes might not need to scale, because of how things are already implemented, and it doesn’t really matter to me.)

Things are further complicated because I’m using a Dvorak/Cmd-QWERTY layout, which is buggy and means that I can easily select notes in Scapple and ‘make font smaller’ with cmd-minus, but cmd-plus doesn’t work; this small issue is an annoyance I have in other apps as well. But this issue is tangential to the main point, which is that I think it could be a great behavior, and one which is clearly within the potentials of the technology.

OS X touchpad users are quite used to the pinch behavior that scales the view (and this works in Scapple as well); this visual logic is similar, except that the objects, the fonts, and the spatial relationship among objects would all scale together. That means one could easily subordinate [or superordinate] a whole section of a figure to another easily, and then zoom in and out to follow all the nesting. In a way, this adds depth to the field-- rather than merely vertical and horizontal control, a sense of zooming to higher and lower levels of granularity or relatedness becomes possible. I think this would allow for denser relationships and more flexibility in the use of the tool. (As it is, this kind of thing could be accomplished with different note styles, or manually with the inspector-- but it’s labor-intensive for the user, and it’s the software’s job to make it easy to do creative work.)

I use linking in my projects with some success, although I must say that the implementation is a little clunky. Having to add ‘files://’ to the beginning of the URL when dragging a document from the finder into the Link destination: dialog box, not being able to drag and drop from the finder (perhaps adding a modifier key to create a link to the file rather than copying its image-- see Circus Ponies Notebook’s behavior with adding/linking attachments as a good example), having to triple-click with a pause between each click in order to link through to the target document (again, perhaps command-clicking on a link to just go to it?)-- these clunky implementation issues make file linking a less-than-elegant experience.

I really like the product, and I’d really like to use it for even more-- I think it could be a really solid contender and attract a strong customer base, it offers some things that other tools out there don’t come close to. I have a few other things on a ‘wish list,’ but (browsing the forums) I realize there are a million ideas out there, and lots of them don’t appeal to me personally. So I don’t want to be just another eccentric, demanding user who thinks their idea is great and universally applicable… but I do think it could come in handy for a lot of people, and it might not be that hard to make happen.

I imagine a future where Scapple is a strong information manager / storyboarder / wiki for creative projects-- like an elegant Tinderbox without all the coding/control stuff. Maybe that’s not the direction the team wants to take things in, but that’s what I think would be really cool. I’m using it to plan my dissertation proposal, and that’s a complicated task. It’s non-linear, semi-hierarchical, and densely interconnected.

Scrivener is non-linear, but still fundamentally linear-- the binder is a list, the document is still basically a scroll, but it’s (quasi-)infinitely divisible, nestable, and meta-taggable. Scapple is great because it’s hierarchy agnostic, but within that agnosticism, I wish it still had better support for hierarchy. Lines with arrowheads is one way, containers is another, this scaling thing (if doable given the codebase and however the object positioning/font stuff has been implemented-- and who knows, maybe there’s already an easy library or function call that could do it!) would be another powerful way to add hierarchy (and really do anything that scaling could convey for people-- a use case could be as simple as pulling part of a Scapple out and easily resizing it for export to a print format!).

My (more than 2)¢.

Thanks for keeping the dialogue open and being so responsive,

Thanks for sharing your thoughts, there is some interesting reading in there on how you use the program. I think your scaling idea is an interesting one, and indeed it is something that has been discussed in the past on these forums. The main problem with the idea is, as you point out, that text size is used as the unit of measurement in the software, and that zooming directly relates to scaling the font size. While you can set your default font size to something huge like 82pt and zoom all the way out, giving you a large amount of latitude for creating micro-clusters, the visual presentation of this leaves something to be desired since the visual effects such as arrow heads and note borders scale as well. Plus there is the whole problem of the default text size being something you set universally, so scaling into an area of the board and working at a smaller point size for a while means changing a preference. It’s very obviously not designed to work this way, even though you can kind of force it.

But a true scalable interface that allows “infinite” zooming so that one can use zoom as hierarchy is a whole lot more difficult to implement than the direction that we took (and this was never meant to be a hugely complicated thing for you or us, Scrivener is our bread and butter, this is just meant to be a nice utility on the side that addresses a different type of thinking than Scrivener and most visual outlining programs). It’s an interesting idea, but it would probably require a total revamp of the entire drawing engine to really pull this off in a way that we’d be proud of having in the software.

Mac menus are nearly always customisable. Check out the System Preferences : Keyboard : Shortcuts pane.

Hmm, that should already be working just fine as a matter of fact. Are you using the latest version of the software? This was refined after the initial launch in response the fact that lots of people ended up wanting to link to files on their boards. Now you should just be able to drag and drop a .scap file into another and get a link without any fuss. This works for anything other than stuff that you can legitimately import, such as images and text files.

I do hear you on the triple-click thing though. That’s something I have on the list as well, but it’s a difficult problem to solve. You mention Notebook, but that’s a text view. When you toggle out of editing in Scapple, the text you’re looking at is actually a picture of the text, at a technical level. So the concept of a hyperlink somewhere inside of that text (and potentially not all of the text, or even one per note) isn’t as easy to implement as you might think.

Thanks again.

Gotcha. Yeah, that makes sense-- not being a developer myself, I don’t really understand the different drawing models and their implementation, although there’s certainly a wide variety of behaviors out there. :wink: Assuming scalar relationships between font size and display box, it might be possible to peg font size increase and bounding box dimension increase-- like 12 pt font and a box with area 3 wide and 2 high, and scale it 2x (to 24pts and 6 x 4) [or any decimal scale]. But I don’t really know how this would work on the implementation level.

The connecting lines appear to change based on the center of the text shape, so that might come along fine (assuming a workable good-enough-scaling relationship between font size and note dimensions). Again, I’m not a developer, but there are some notes on the cocoa transforms here:

And somehow the behavior of the bounding-box drag cursor would have to change-- maybe a hover over a horizontal edge would give the edge drag (to replicate current behavior of resizing the width of text boxes) and a hover over a corner would enable this hypothetical scaling function.

But yeah, I get that it might not be possible-- but here I guess I’m wondering if a complete rewrite would really be necessary. Anyhow…

Thanks, will do-- I thought it would just work out of the box, but there aren’t all that many Dvorak users, not to speak of Dvorak-QWERTY users… :wink: I think it has to do with cmd-plus actually being cmd-shift-left-bracket in dvorak, and what catches that at what point in the OS… but I’ll try to overcorrect as you suggest. :wink:

Thanks, my mistake-- works just fine.

What about whole notes as links, similar to web images wrapped in an <a href= > ? This would mimic things like image links on the web (which people are used to).

That doesn’t really address the click-through for text links issue, thought, and it breaks with a design choice that has already been made. Something like generating an imagemap for each text image seems pretty unwieldy, I guess… Or maybe something that would generate an imagemap upon mouseover (or mouseover plus modifier key) so that the area displaying a text link would become ‘hot’? Weird workarond, I guess…

→ or maybe make the mouseover + modifier key be a way to enter editing mode-- that way, a command-click would effectively use the link.
Only problem here is that inline elements (one-line or short notes) have a weird behavior in that they display a bit wider in editing mode-- so the cmd-mouseover would replicate this behavior.

I can’t help but think the scaling thing could be addressed somehow-- I think the way that scapple treats inline and box elements could be bridged, the inline elements could be converted to a box before the transform and then changed back to an inline element-- but whatever, I’m not the developer and won’t be doing the work, obviously… :slight_smile:

Thanks again for your thoughtful reply.

Although I suppose that might break the functioning of other command key combinations, which doesn’t seem particularly helpful.