Sketch System Principles and Mechanix Feedback

What a Sketch System Should Do:

1. Pressure-based line thickness. Though this is a recent development and is highly dependent on hardware, it greatly enhances the feeling of 
2. Use a stylus as its primary input method. Most touch systems of today use finger touch, but finger paint is an extremely limited subset of all kinds of paper sketching/painting. Stylus sketching is far more reflective of the type of sketching most people do on paper
3. Beautify strokes to appear as seamless as possible. Work to remove any jarring angular changes in sketches resulting from the touchscreen hardware. The more pixelated a sketch looks, the more it breaks the immersion of writing as one would on paper
4. Stroke deletion. Ensure that the system supports deleting entire strokes at a time. Although this does not reflects the realism of writing on actual paper, deleting entire strokes at a time is extremely convenient for anything other than drawing applications. It should at least be an option
5. Zoom in/out, translate. Since touch surfaces are typically smaller than regular pieces of paper (especially true of tablets), the user should be able to zoom in, out, and translate the page across a zoomed in version to better suit the user's preferred comfort of sketch size.
6. Have a non-intrusive interface. Interfaces in sketching is unlike any other kind of system. Features cannot be buried under menus, nor can every feature be listed at once. Features should be smartly presented and removed in such a way that it interferes as little as possible with the actual sketching
7. As big a sketch area as possible. Sketch areas should not stop strictly at the edge of the window. They should be easily and intuitively be resized. Avoid using the "Windows resize arrow" style of resizing, as it does not work well with a stylus or touchscreen.
8. Have a grid, unless it is a drawing application. Most every piece of paper, from regular writing to architecture sketching to mathematical formulas, all have notebook lines or grids to aid the user's writing task. Completely blank pages are only suitable for art drawing and should only be default if the application is intended for that domain
9. Provide ample amounts of stroke size and color options. Users are more creative when given stroke size and color choices, and frequently aid them when sketching for homework or productivity tasks. They are both fun in recreational use and useful in productivity tasks.
10. Simulate the on-paper experience as much as possible. The most successful sketch systems are the ones where a user acclimated to the system "forgets" he or she is writing on a digital surface when sketching or writing. All sketching system should strive for this kind of user experience.

What a Sketch System Should Not Do:

1. Aggressively auto-correct. While some beautification is expected, snapping lines to make them perfectly straight and at predetermined angles 100% of the time is jarring and removes a user's sense of agency.
2. Be laggy. A sketch system should have little to no lag between the user input and the sketch showing. Significant lag can break immersion at best and render the entire application useless at worst. A lag-less system is vital to capturing the illusion of writing on a regular piece of paper
3. Be "heavy". "Heavy" systems, whether in terms of computing power, or in terms of file size when saving sketches, is vastly inefficient and adds a layer of technology-borne burden that otherwise would not exist on regular paper.
4. Write or preserve a "mouse-based" interface. Do not assume that users have access to a mouse to complement their sketching needs, and thus do not use small interface items optimized for mice. Assume that the user will want to reach every last item of the UI through stylus or finger only.
5. Be strict in sketch order. Especially with sketches that are to be analyzed by a system, expecting users to know the order in which sketches should be drawn is highly unintuitive and should be completely avoided.
6. Fault the user for misinterpreted shapes. Nearly everyone is sure that the shapes they draw are "correct". If a stroke is misinterpreted, do not say "you have drawn this incorrectly", or something to that effect, as it is overly antagonistic and isn't in the spirit of free-hand sketching
7. Have the user spend more time on the UI than sketching. Digitized applications can always come with a plethora of options and features, but with sketching, less is more. Sketch systems should not see their users spend more time navigating and "figuring out" the UI than actually sketching.
8. Mix stylus with touch sketching at the same time. If the user is sketching with a stylus, disable all touch-based input and vice versa. Most people rest their hands on the paper when writing, so they do not expect the side of their hand to actually be involved with the writing process.
9. Use pre-determined shapes as a primary method of sketching. Paper sketching does not afford dragging and dropping items as a primary input method. These tasks are far more suited for more traditional, mouse-based systems.
10. Use non-paper backgrounds or patterns. Do not visually model the drawing surface aesthetic as anything other than what a person would reasonably expect to be a writing surface. Avoid the use of unusual colors or patterns that do not in any way resemble a drawing surface. This does not mean all interface should be skeuomorphic, it simply means they should not be so far removed from a writing experience that it is jarring to users.

Improvements for Mechanix:

1. Optimize idle CPU load. The CPU is always being "used" in Mechanix, even during idle time. This greatly drains batteries and runs hardware hot, which in a more tablet-based industry is quickly becoming unacceptable for users.
2. Save student progress on the database. Maintaining saved, partially completed homework assignments locally is not portable. Since the MCX system is online-only, there shouldn't be "I left my homework at home" scenarios of the offline world.
3. Re-think the items displayed on the drop-down menus. Some features are experimental, some antiquated, some buggy. For the user build, we should comb through what is shown on these and remove the ones that aren't intended for a student to use in his or her homework assignment.
4. Alter color palette. Some of the contrasting colors can be rethought to better suit the homework style for MCX. Green-on-white for the description of solved problems, for instance, strains the eyes too much.
5. UI scaling. Although this is a big task, most computers having a wide range of resolutions among them means Mechanix should implement UI scaling to preserve the user experience. Users with lower resolutions have considerably more trouble with much smaller sketching areas.