tqs

With a Pro account you can upload your own font files.

You may be interested in Cuttle’s Connected Text feature. This will automatically connect dots on i’s, etc so you can cut out text in one piece. There’s also an option to “thicken” text so it’s not as delicate.

You can try a live demo here: https://cuttle.xyz/@cuttle/Connected-Text-29M9IXUSr5yr

That page also describes the algorithm we use to make this work with any font.

To export multiple components, we usually create a component (called “Cut Layout” for example), then drag out each of the other components (the pieces) into that component.

There is a modifier called Flatten which might be useful for you for doing lots of Boolean operations at once. I think this video shows the workflow, https://www.youtube.com/watch?v=LGHKRfIC6QA

Yes it’s all JS. You could copy and paste your data in and then process it and create geometry. (Sorry we don’t have any data import other than copy and paste at the moment.) Our scripting documentation is pretty good: https://cuttle.xyz/learn/scripting/getting-started-with-scri...

We are experimenting with being able to read pixel values of raster images. Coming soon likely.

Perhaps some kind of middle tier that gives full access to the Editor but does not give full access to the Pro templates makes sense. Many of our customers subscribe for access to those templates rather than the Editor!

You are also free to subscribe when working on a project and need the Pro features, then cancel when you’re dormant. We don’t delete your projects when you downgrade to free, you can still access/edit/download them.

I appreciate the feedback and the questions!

At the same time you can do arbitrary “drawing” with a bezier pen tool and move/transform shapes. In this case you are essentially using the canvas drag-and-drop to manipulate literals in the program.

But fundamentally a Cuttle project is a program and the Cuttle Editor is an IDE that looks like a vector editor on the surface.

Because of this I’m not sure how much of Cuttle could be grafted onto a program whose architecture is more rooted as an editor of static vector graphics. I do know that Inkscape has some “live effects” which are similar to Cuttle’s “live” modifiers.

If you are interested in Cuttle’s architecture, I did a one hour walkthrough on this interview, https://www.youtube.com/watch?v=2el-85vG-IU

We don't laser cut anything for you. You can download your project as an SVG file (or DXF, etc) which you can then send to a laser cutter hooked up to your computer.

The product is designed for people who have access to a laser cutter, e.g. at home or at a makerspace.

From a programmer's perspective, you can think of Cuttle as a direct manipulation vector editor (like Inkscape or Adobe Illustrator) that can be driven with parameters and JS code where you need it.

Unlike my previous research projects, this is a commercial startup mostly catering to laser cutting small businesses, though you can use it for anything where you want a 2D vector editor + some programmatic capabilities.

I'll try to answer questions that come up in this HN thread.

Thank you for sharing your work Hannah! Very cool stuff!

Raskin emphasized that "modes" were a major cause of UI problems. Essentially you want a UI that the user can habituate to as strongly as possible, so that all one's attention can be focused on the actual task and all of the administrivia you need to do tell the computer your intention are handled subconsciously. Like touch typing at a higher level.

The issue with modes is that they break habituation. If performing a given UI gesture does one thing in one mode and another thing in another mode, you can't make that gesture a habit. For example: Cmd+Z is a conventional gesture that many applications interpret as undo. If the keyboard shortcut changed between applications (or worse Cmd+Z meant something else in another application/mode), it wouldn't be so habitual and you'd be less productive.

Raskin was very serious about no modes. The Cat for example didn't even have an on/off mode. It would go to sleep to save power, but if you started typing it would buffer all your key strokes and have them in your document by the time the thing woke up. That is, you didn't have to switch from off mode to on mode! And because you were always in a document (that is, there were no separate application modes), you knew that typing some words always did the same thing, so the scheme really worked.

On the other hand, Apple has really pushed, especially since iOS, on the "App" model. Applications are, of course, giant modes. And the strategy has been to push a separate App (mode) for every single use of the machine. So rather than learning a few powerful gestures and then combining them to do disparate tasks, users need to learn a separate, surface-level gesture complex (App) for each individual task they want to do on their machine.

Which is more efficient or appealing? On what time scale of use?

Did Apple end up this way because Apps are a more natural fit for a consumerist model? "Want to do this task with your machine? Don't bother figuring out how you can do it yourself. There's an App for that!" No Modes vs Buy More Modes?

Raskin's book, The Humane Interface, talks extensively about his UI design philosophy. In addition to explaining the above problems with modes, he discusses how to actually design a computer system with no modes (I believe an elaboration of what he did with the Cat). He also explains other really important UI principles and their ramifications, for example, "The user's data is sacred" (hence undo).

PS:

Raskin's definitions: A gesture is defined as an action that can be done automatically by the body as soon as the brain "gives the command". So Cmd+Z is a gesture, as is typing the word "brain". What constitutes a single gesture will be different depending on the user! A mode is defined as any situation not at the user's locus of attention that would cause a gesture to perform an action different from another mode. So "pseudomodes" where the user holds down a modifier key or holds the mouse button while performing a drag gesture get around this since they keep the user's locus of attention on the fact that they are performing the pseudomode.

I think both the above definitions are still a bit problematic but Raskin's definitions are better than any other that I've heard. I hope there are more people who study and discuss these deep UI design issues! What do you think about modes?

I'm glad you're thinking about how to manage garbage collection. It's tricky with these push-based frameworks.

Have you given consideration to asynchronous vs synchronous reactivity? The advantage of asynchronous is you don't propagate the changes as they are made but instead once all the changes are done. You can avoid redundant computations this way, for example if a bind is dependent on multiple observables that change in the same "turn". And in some ways (worth debating) asynchronous semantics are more understandable than synchronous since unknown code is not being run underneath you while you are in the middle of changing observables.

Here's Ember's writeup on their rationale for asynchronous: http://emberjs.com/guides/understanding-ember/managing-async...

Also since Object.observe is asynchronous, Google's polymer/MDV will also I believe have these semantics.

Around 1960, most were still thinking of the computer as a sophisticated calculator. You give it a problem, it spits out an answer. Even the idea of artificial intelligence was framed this way.

Engelbart realized the potential of the computer to augment human intelligence. High bandwidth, continuous interaction between human and computer allows the computer to be an extension of the mind. Chasing this vision led him and his team to naturally invent the mouse, bitmapped screens, hypertext, networked computers, etc.

IMO, more important than these individual inventions is Engelbart's foundational principle that technologies change what the mind is capable of thinking. And by augmenting our thinking, we enable ourselves to create new technologies. Mind and technology co-evolve. This is "bootstrapping" in the purest sense and the source of that profound feeling many of us have experienced while augmenting our minds through programming and other rich, creative interactions with computers.

Seriously is a JS library for handling the boilerplate of WebGL, composing and compositing multiple shaders in a pipeline/graph, and adjusting their parameters. In addition it comes with a bunch of pre-written shaders.

Shaders themselves are a lot of fun to write, IMO. A pixel shader is just a function that computes a color given an input pixel location. (A shader can also take in additional input such as "textures" to sample from, e.g. a video frame.)

The shader is run with massive parallelization in the GPU. In theory every pixel can be processed simultaneously. This is how these effects can run in real time.

Here are some more examples of what you can do with pixel shaders (including sampling from the webcam in the browser -- should work in Chrome and FF), http://pixelshaders.com/examples/

I'm in the process of writing an interactive book about pixel shaders, http://pixelshaders.com/

http://en.wikipedia.org/wiki/Placebo_button

When you drag and drop the shapes, the drawing changes in non-trivial ways. For example, try dragging a shape deep down in the recursion hierarchy.

In a normal drag-and-drop application, it's fairly easy to compute how to, say, adjust the left/top of a div in response to the mouse movement events. However, with Recursive Drawing, I knew that there were certain properties I'd have to adjust during a drag operation, but because of all the nested transformations, it was tricky to figure out the math of how exactly to adjust them.

So instead, I set up a constraint problem. I know that the exact spot I've mousedown'ed on needs to stay under my mouse no matter what. That's the fundamental constraint of the drag-and-drop gesture. Then I set the properties that I knew I could change (e.g. positions or scaling/rotation of a specific shape) and set them as free variables in an energy minimization function. I solved the problem numerically using numeric.js's uncmin (unconstrained minimization, an algorithm originally written in FORTRAN, I believe).

I probably could have figured out how to do this without numerical methods, but this approach was a god-send when rapid prototyping the interactions.

Another good use of constraint systems for UIs is Ivan Sutherland's Sketchpad. His paper on it is long but really worth at least skimming through if you're interested in developing next-generation UIs! http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-574.pdf

I also really like Rebecca Fiebrink's Wekinator, which is a framework for making musical instruments from arbitrary inputs. The approach is similar in that she uses numerical methods to solve for the constraints (the training data). http://wekinator.cs.princeton.edu/

I think there's a lot of potential in constraint-based UIs and for me it's the most compelling reason to have good numerical libraries in javascript.

Can you give an overview of how your library is different? Is it just a different set of math tools or is the architecture somehow different? Thanks!

http://www.opus-codec.org/ https://wiki.xiph.org/OpusFAQ

That is, his key innovation was a way to mass-produce the characters (the movable type) which could then be arranged to mass-produce the printed pages.

First, individual characters were carved from steel (each taking about a day to make). This was the only part of the process done "by hand". Every other element of the process was produced through some form of (repeatable/arrangeable) transfer of shape/information.

The master characters were hammered into brass to create a mold which could then be reused to cast multiple copies of a character. Each page had thousands of characters and Gutenberg's shop had multiple presses going at a time, so they needed lots of these characters on hand (50,000 is a conservative estimate).

The masters could also be easily transported to another city. These masters (plus raw materials of course) were all that was needed to set up a new print shop. This enabled the printing press technology to quickly spread throughout Europe.

I think it's a good analogy for the power of software :)

Source: http://retinart.net/beautiful-things/gutenberg-book-changed-...

In Opa (as I understand it--I haven't used it), the programmer can be explicit about where code execution should occur, but the compiler can also infer where it should occur, determine the best place to put the "data boundary", and warn the programmer if code is executed in an unsafe context.

For "traditional" next-gen web apps, it's a tough call that this is enough of a win to warrant learning a new language. Further, because this style of server-client programming is pretty immature, programmers may want to have tight control over where code is run.

However, I think this is very important work for the future of distributed computing. In particular, consider if we are ever to move from the web's dominant server-client architecture to a more fluid peer-to-peer model, with code moving from client to client where appropriate (i.e. mobile agents). For example, say my phone needs to grab some data from my laptop, but rather than have the laptop send all the raw data to my phone and have my phone process it, the system figures out that it would be more efficient for my phone to send code to my laptop, have the laptop process the data locally, then send the processed data back to my phone.

To be able to make inferences like in that example, I think we will need to use approaches like Opa.

So by less syntax you mean fewer syntactic forms (parentheses, curly braces, do notation, etc.) and keywords (class, public, etc.) in the language.

I think in general, languages with fewer syntactic forms also have fewer but more powerful abstraction features. Lisps are pretty high up by this measure. They basically only have one abstraction feature: lambda expressions. Other languages have powerful abstraction features but more of them, like Haskell (lambdas, pattern matching, monadic do notation). And others have many but less powerful abstraction features (e.g. Java).

On the one hand, I certainly agree with you that more powerful abstractions make it easier to program. Once you've grokked the abstraction, you only need one brain "chunk" to deal with it freeing up your other chunks to work on the problem. If you need to juggle several different abstractions (e.g. wrap up your closure inside an object inside a class), you have fewer chunks to work on your problem.

On the other hand, people tend to have difficulty learning these higher abstractions in the first place. Alan Kay, in that quote, points out that young children (I think less than ~8 years old) have difficulty with the abstraction of parameterization. In particular they have trouble with mentally corresponding the placement of a parameter in a list with its role in the function. Named parameters make things a bit better, they help the children keep track of the role. Explicit variable assignment (imperative programming) makes it even easier. Of course, as less powerful abstractions, these styles don't tend to scale as well when working on more complex programs.

In general, I think people need help keeping track of specifics while working with higher abstractions until the abstractions become "natural" to them. Programming interfaces, including debugging interfaces, can help with this.

It's a bit of a paradox. When you truly understand an abstraction it tremendously improves the clarity of your programming experience. But without this understanding, abstractions can be a major hindrance.

You may be interested in further exploring "point-free" abstractions. It's kind of the next level up the abstraction ladder from explicitly assigned variables in imperative code, to lambda abstractions with parameters, to functions without the parameters at all. http://www.haskell.org/haskellwiki/Pointfree

Or approach from the concatenative side, http://evincarofautumn.blogspot.com/2012/02/why-concatenativ...

Coffeescript vs Javascript forms a good case study because they largely have the same semantics but with different syntax for key features.

To my mind, the big difference with Coffeescript is the syntax for functions, e.g.

(x) -> x * x

vs.

function (x) { return x * x; }

Coffeescript's syntax eliminates "function" and "return", which significantly lightens the syntactic weight for functions.

I would assume on average that Coffeescripters write significantly more functions than Javascripters (say, for normalization, per bytes of minified JS). This assumption is based on reinforcing selective pressures: Coffeescript encourages programmers to write more functions, and programmers who want to write more functions choose Coffeescript.

Alan Kay has been studying how children take to programming and many of the ideas from Smalltalk come from these studies.

When designing for children, every part of the user interface, including the syntax of the programming language, matters a lot. For example, he writes, "If we take functional relationships as an example, it has been shown that children readily understand them but have considerable difficulty with variables, and much more difficulty with parameters. The standard math syntax for functions with parameters requires some extra trained chunks to associated dummy names with actual parameters. Some computer languages allow conventions for prefixing the actual parameters with the dummy names. This is good. For younger children, it's likely that making these into complete assignment statements is an even better idea. An object oriented language can use instance variables for a long time before introducing the idea of passing parameters in a method, etc. Having really good trace and single-step visualizations is critical." http://www.donhopkins.com/drupal/node/140

Children have different cognitive needs than adult programmers (and different needs from each other depending on age). But cognitive needs matter in designing programming languages for adults too. I personally take the optimistic (or cynical?) view that we have a lot of room to improve our programming interfaces (not just languages, but the entire programming experience viewed holistically).

It's based on the Music Genome Project. For over 8 years, they've been having highly trained musicologists listen to each song individually, then manually categorize them on ~400 attributes (e.g. is it syncopated? major or minor key? does it have vocal harmonies? etc). Pandora uses this data to find similar songs to the ones you like.

You'd think it wouldn't scale but Pandora seems to be doing it.

"The Music Genome Project's database is built using a methodology that includes the use of precisely defined terminology, a consistent frame of reference, redundant analysis, and ongoing quality control to ensure that data integrity remains reliably high. Pandora does not use machine-listening or other forms of automated data extraction." http://www.pandora.com/about/mgp