mitmedialab / para

Para: Procedural drawing with direct manipulation

Para is a digital illustration tool tool that uses direct manipulation to define and edit procedural artwork. Through creating and altering vector paths, artists can define iterative distributions and parametric constraints.

Para began as opensource software in the Creative Technologies Lab at Adobe Research. Currently, Para is under development in the Lifelong Kindergarten Group at the MIT Media Lab. The software is part of a research project in broadening participation in procedural art and design. Para is maintained by Jennifer Jacobs of the MIT Media Lab, with contributions from Joel Brandt and Radomír Měch of Adobe Research.

Build Instructions

If you want to build from this repository you must install node.js and the Grunt CLI. Then, from inside the para source directory, run:

npm install

bower install

grunt build

If the build is successful, you should be able to run para locally from your browser by navigating to the build folder within the para repository and opening para.html. For best results, run it in Chrome.

License

The MIT License (MIT)

Copyright (c) 2014 Jennifer Jacobs

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

para's Issues

selecting property in constraint tool for reference shape causes shape to be drawn on top of UI elements

copy shape is being redrawn on top of other instances. Does not happen for the relative shape.

migrate to desktop app

Should Para be a desktop app at some point? Electron is more mature at this point and looks like it could provide a viable solution without too much headache. Possibly something to explore in the future. Could be one way of addressing #38

handling over-constrained drawings/ constraint cycles

It's currently possible for the user to create a constraint cycle with para constraints. We can detect constraint cycles by implementing an algorithm to detect strongly connected components in the constraint manager. (Something like this.)

Short term fix is to detect when a constraint will cause a cycle, and simply prevent people from creating such constraints. A notification with a dialog box should suffice.

A more elegant interaction fix can be implemented when we have a better idea of the specific challenges of managing highly constrained complex compositions..

Set self-referencing constraints on proxy rather than actual object

Partially implemented in the duplicator class already. Would also enable 1 way constraints to be updated by using the relative object as a proxy to update the reference object.
Requires development of an interface to designate and remove proxies..

enable constraints to be copied or applied to different relatives/references

users should be able to select a constraint in the layers panel and modify the reference and relative objects, possibly by dragging the endpoints of the arrow which indicates the reference and relative objects to new layers. As an additional enhancement, users should be able to copy an existing constraint and designate new relative and reference objects.

relative rotation not maintained on constraint

when constraining on rotation, after the constraint is created, the relative object will match the rotation of the reference rather than maintaining a relative constraint based on its current rotation.

complete refactor of ConstrainableList class

ConstrainableList currently in the process of being refactored to better support passing iterative constraints onto members. This needs to be resolved before iterative constraints can be completely implemented. Currently this occurs by modifying the transformation matrices of the members prior to render. This must occur in a manner that prioritizes pre-existing constraints on each member, so that collection constraints do not override individual constraints. Should be done in concert with #40 in order to provide better interface to modifying the transformation matrices.

property-override toggle is broken

instances do not revert to their parent's property when property override is toggled in the toolbar

move management of selected shapes to visitor class

Currently they are stored in the select tool class. Moving to the visitor class will help to reduce the amount of event handing code we need to manage shape selection

add constraint apply button

Right now constraints are applied with the caps lock key. Implement an apply button in the top toolbar which appears and becomes active when the constraint tool is in use and has a relative and reference object selected.

complete implementation of pen tool add and subtract point mode

When pen tool is clicked on an existing path, it should add a point, when clicked over an existing point it should remove that point. The hit detection for this has already been implemented in the pen tool but needs to be adapted to access the paths of the currently created instances.

Implement tab functionality in color UI

selecting tabs on fill and color ui should bring up additional options (HSB selectors)

logic on scale constraint toggle is malfunctioning

difficult to toggle between x only, y only or x and y scale constraints. There seems to be an issue with the logic that dictates when a switch can be made between these states. Logic is working for correctly for defaulting to x and y scale when both x and y are constrained individually. Possibly a simpler solution is to just make one scale button that toggles between 4 states, x scale, y scale, x and y, and no constraint, similar to the proposed approach for the position toggle.

fix bare-bones saving functionality or implement more robust form of saving

Due to iterations in the design of para, the saving functionality is currently broken. Prior to any user study, we need a bare bones version of saving implemented again. It's open for discussion for how much effort we should put into a more robust version of saving- for example the ability for users to save their files remotely and access them later...

Should the visibility of objects be constrainable?

Should we consider changing visible attribute to a constrainable attribute? Currently it's just a standard boolean and cannot be constrained to the visibility of other objects. As a result it's not accessed in the same way as constrainable attributes (accessProperty). Are there clear use cases for constraints on object visibility?

constraint apply button does not indicate correct status after constraint is applied

apply button should fade to 0.5 opacity when inactive- however immediately following the successful application of a constraint, it retains its opacity value. This is a js issue, not a css issue.

filter shapes and lists panel based on selected list

enable filter mode for shapes and lists panel when list is selected, so that only shapes and other lists contained in the collection (or other collections contained in the collection) are highlighted or visible.

Will require modifying the fork of FancyTree to achieve the UI changes:https://github.com/pixelmaid/fancytree

SVG import

enable users to import vector graphics created in other software as svgs.

mapping tool for iterative constraints on collection

Implement a mechanism to describe a mapping from a reference constraint value to each member of a collection as a function of its index. Current plan is to use a graph dialog to describe the function:

architecture for describing iterative constraints is in place, but UI needs to be implemented.

constrain collection within a manually drawn path

Similar to #58, but constraining collection of shapes within a manually drawn path rather than along it. Would be useful to have a brainstorm on possible use-cases or specific functionality for this type of behavior.

implement ability to automate instantiation of shapes

User should be able to automate the process of creating copies of a shape (as instances) and have them placed into a pre-existing collection. A possible interaction description of this process is listed in the paper draft in the iteration and automation section: https://www.sharelatex.com/project/54f8d8616000dcb04565fb70

implement UI for constraining to individual points

Users should be able to constrain the x,y position of points, as well as use them as references for constraining other objects, both points and shapes. Current constraint architecture supports this, however the constraint UI needs to be modified to support a mode where points are selected rather than the entire shape. In addition the constraint UX should be modified in point mode so that only the selectors for position are viewable, rather than including all property selectors (rotation, scale color etc).

simultaneous constraining of x and y position does not work correctly

simultaneously setting constraint to x and y position causes the relative object to be constrained to 0,0 rather than to a relative position to the reference object.

refactor naming conventions from List to Collection

We are using the term collection to refer to an ordered list of object. All classes dealing with collections should have their names changed to reflect this terminology.

clear does not clear object in layers panel

clear operation does not affect layers panel reference.

remove arrow on constraints on canvas

Para currently draws an arrow between the two objects being constrained on the canvas. From a UI perspective, this seems to only make sense if the user is constraining the position of the objects, otherwise it's somewhat misleading. It also stops working when the objects being constrained are extremely close together or overlapping. We also already have an arrow visualization proposed for the layers panel (#31) which seems to duplicate the functionality of the arrow on the canvas.

A better approach may be to outline the objects being constrained in colors corresponding to their status (red for reference, blue for relative), and/or to decrease the visibility of all other objects not being affected by the constraint.

consider changing constraint position ui to toggle rather than to x y selection

Possibly change constraint ui setting to a button which toggles between 4 states: constrain x and y, constrain only x, constrain only y, and no position constraint. Would enable a bigger hit area as well.

toggle bug in color constraint UI

toggling off one sub property when 2 sub properties are selected defaults to entire property

SVG export

was implemented in the original version, but has since become non-functional due to changes in the architecture. Should be completed in concert with #38

Functions, or method for re-using collections of constraints

we've experimented with creating something resembling functions in Para, but haven't converged on an approach, or a definition of what use cases functions serve in Para. They could serve as a method for generalizing an existing set of constraints and re-mapping them to different/ multiple sets of shapes. We also need to figure out the interaction design surrounding functions: the current thinking is to appropriate layer masks UI to address this.

fade animation on instances is broken

instances do not fade in and out anymore when the parent object is selected and about to be manipulated

enable constraints to be removed

Currently constraints can be created, but not removed. This should be enabled in the layers panel in the constraints section.

conditional constraints

Although the system technically supports them, there's currently no way to describe conditionals in Para. It's unclear how conditionals can be described in a direct manipulation, visual interaction in an expressive way. A brainstorm about possible concrete use cases for conditionals might help us to think about what the UI for conditionals might look like, and how they might be visually represented in the system.

implement constraint visualization in layers panel

when a constraint is selected, a vertical arrow should appear between the two objects that are constrained to show relative and reference objects.

implement function mapping for 1 to 1 constraints

When constraining between two objects, the user can currently define a relative function where the reference is constrained to the value of the reference + some offset value. it may be desirable for the user to be able to specify a more complex function which describes how the relative object should change in response to the reference. For this, a dialog similar to the one proposed for the iterative lists (see #41)

Unclear right now if this is actually useful for static compositions, but it would definitely be useful for animation applications.

ability to constrain properties to a random value

To make interesting procedural art, para needs some form of random noise. Primary questions are:

1. what is the visual representation for random noise (i.e. some node in the canvas, or some functionality in a toolbar or palette)?
2. How should the UI be designed to support it (i.e. specifying range of randomness, specifying when to re-generate random values)?
3. How do we implement the calculation of random values in a way that meshes with the liveness of para?

One possible direction is to have a mode on the constraint mapping tool which enables the user to define a set of random values in between a range specified on a 2-axis graph.

constraint wheel created even when no object is selected

line 207 of ConstraintToolModel.js
Creates a constraint wheel when no objects are selected, resulting in an access error and a floating constraint wheel on the screen.

Constrain position of collection members to path

reproduce functionality from original version of para to constrain a collection of shapes along a path. Need to figure out if this is a baked-in feature, or a behavior comprised of lower-level constraints. My inclination is to do the former first, then get user feedback on ways that we might migrate to the latter..

implement UI to constrain on color

Requires 2 additions to the constraint UI: 1) a color selection toggle to the basic UI, 2) a secondary dialog for specifying constraining on either stroke or fill, and the ability to specify the color representation to constrain by (RGB or HSB).

clean up generalized constraint code

There's currently a hack in place for the logic that specifies constraining between a single dimension of an multidimensional property and a basic value (ie x position and rotation). The code works, but could be cleaned up.

https://github.com/mitmedialab/para/blob/861d9073d9f6becee509e1b6f44670c005929594/js/src/models/data/Constraint.js#L125-126
https://github.com/mitmedialab/para/blob/861d9073d9f6becee509e1b6f44670c005929594/js/src/models/data/Constraint.js#L300-301

refactor mechanism for storing and accessing selected objects

Currently the selected objects are managed by the SelectTool class. It seems like a better solution to have this be managed by the visitor class, and enable other classes to request access to the selected objects via the visitor.

refactor visitor class

The visitor class needs to be refactored into a manager for visiting and updating constraints, collections, functions and instances. A function manager class already exists and should be used as the template for creating similar managers for instances and collections. uncertain what the status of constraints are: are they managed via the constraint tool?

re-implement analytics for new version

analytics code already exists, but calls to the tracking functions need to be re-integrated with the new tool code.

re-implement undo and redo

The architecture for this is already in place through most of the system as shapes and collections can be exported as JSON objects. We should continue using backbone-undo for the implementation.

proxy mode is not working

proxy mode does not currently enable instances to be used to edit their parents

refactor interface for instance class

The instance class needs a cleaner interface for specifying changes to its properties. Right now all properties can be edited through the modifyProperty function which accepts an object specifying the property to be modified, the value, and the modification operation (add or set). Separate public methods for modifying each property should be designated which in turn call the modifyProperty, which should be designated as private. The same thing needs to be done for accessProperty (the get method for an instance's property).

cannot add points to a path after a point is removed

when drawing a path with the pen tool, if a point is subtracted with the tool, new anchor points cannot be created on the curves of the path until a new anchor point is created.

error in applying point transformations to inheritors when shape is rotated

transforming the point of an object will not provide the desired transformation on its inheritors if the shape has a rotation value other than 0.

display numeric parameters of shape in property bar

width, height, x and y position, scale etc. should be displayed in property bar in a numerically editable format when a shape is selected. Some of the architecture for this is already in place but got broken in the last refactor.

enable user to define constraints on collections which constrain members relative to the origin of the collection

Currently constraints on collections individually map to each member of the collection. It seems likely that users might also want to create constraints that treat the the collection as a geometric grouping and have each member constrained relative to the origin of the collection. This requires some re-working of the collection class architecture, but the harder challenge is in determining the UI interactions for enabling a user to distinguish between a relative constraint and a iterative constraint on a collection, and how that is represented in the interface.