Rant and Yammer

@falets-blog

43 posts

45 Seconds?

The Industrial Revolution and invention of mass production are among the most important foundational pillars of modern society. The factory model has enabled more creation of wealth, allowed for faster technological development, and has been a great societal equalizer—providing more goods to more people for less money.

But mass production also carries an innate limitation. It represents, at its core, a compromise. In exchange for reliability, durability, efficiency, and price we give up individuality. The economies of scale and tooling dictate that I, as a customer, must share the same problems, needs, desires, and tastes as thousands or millions of other people in order to have a product designed for me at a price point I can likely afford. For the past 200 years, the rule has been that customization is expensive; often prohibitively so. Mass production is is much cheaper, but it is also a rather imprecise instrument for addressing individual needs.

I have devised a system that shifts the balance of that compromise, at least in the eyewear industry, by using existing and emerging digital technologies to create unique frames for each customer based on fit, function, and personal taste.

Code ?= Dev

As I get into the thick of building out my thesis prototype, I’m digging deeper into the coding frameworks I’ve opted to use; namely AngularJS to drive the front end—though I am also pulling jQuery and jQuery UI—and Flask for the back end. The fact that I even have a back end in place is unique for my program. Most of my classmates are going to serve up static HTML with interactions handled by jQuery or a similar DOM-specific Javascript library, and we often discuss the relative merits of bringing heavier code use into the design mix.

This discussion seems to pervade the IxD world these days, as I frequently see posts on LinkedIn and Facebook, often heated, about whether or not designers should learn to code. It’s probably clear from what I just said about my prototyping process that I think they should, but my position is not so cut an dry as to just say ‘yes.’ I’m on a pretty big deadline and I’m delving into subjects with which I do not have a ton of experience, so I’m possibly on a trajectory to complete disaster. I’ve spent the last few weeks understanding the rather complex beast that is Angular, and getting a nice crash-course in Javascript at the same time, without making much direct headway on my prototype.

I continually question the value of this process. I enjoy writing code, and it’s fun to build something, but I don’t know how critical it is to communicating my design ideas. There are transitions and animations, which I could either allude to through a few static states, or build out in an animation program. But these are getting very easy to build using CSS transitions and I can activate them interactively. I can also drop in images and other styles as I change the design. I doubt I would design anything more complex than a small change in size, color, or opacity anyway, so these are kind of perfect. As for the more complex work, now that I’ve built an understanding of Angular and can quickly build out data bound elements within an application, it actually becomes a huge time saver over either creating multiple static pages or stitching together a fragile patchwork of jQuery DOM changes. I can bring in actual data more easily and, because I’ve taken some time to learn how to modularize my code, I can change parts as needed.

In short, I like this workflow, though it does have a steep learning curve (I still need to know how to use Illustrator, manage type, and consider color as well). I doubt it’s for everyone, and maybe it makes me more of a developer than designer, though I’d rather hope it helps to blur that boundary.

Learning from Prototyping and Storytelling

I’m currently in the process of building what will become my Final Presentation, working simultaneously on creating both the interface experience and presentation that will form my thesis. After all these months of design, development, and testing, I’m amazed at how much will likely change and get refined in the next few, final (gulp) weeks.

For the prototype portion of my thesis, I’m using Flask and Angular to create a mostly-functional web application that I will deploy over the next few weeks. Look for it at my thesis site. I started by developing the main navigation based on earlier wireframes that tested well. Yet, as I incorporated some of these ideas into a higher-fidelity prototype, I noticed core flaws in the original design. When presented with actually seeing two-way data binding take place, a host of problems, and opportunities, showed up. This is not a bad thing in any way, just an observation that, in this case, prototype fidelity has an influence.

Working on the narrative component has been even more enlightening. As much as I wax philosophical about the importance of rhetoric, I know that I am prone to forget it when working on a design. I’d much rather tinker than present. I don’t know if that will be an ongoing struggle throughout my career. We were tasked this week with creating the skeleton framework for our final presentations, a task I typically would find daunting. But in this case I am surprisingly not daunted. As I start to frame out my argument, I an finding its holes, thankfully shaping the scope of thinking and description I need to focus on between now and the end of April.

My Thesis Has a (New) Home

I’ve started moving my process to a dedicated website. I’ll post my prototypes as I develop them, and I plan to eventually migrate this blog there as well.

http://thesis.stevefaletti.com/

User Testing

Coming off of spring break, my thesis is progressing quite well. I’m very comfortable with my direction regarding eyewear, and received some great feedback from my eyewear design contact. In walking through his typical process, I found the consistencies, and holes, with my early prototypes. I have found new a 3D modeling technology—Symvol by Uformia—that should allow us to vectorize the industrial design process somewhat. We will come up with logical breakpoints in a given design and iterate on them separately. The Symvol software will allow us to blend those forms back together and weight the blends. I will expand upon this part of the project in more detail later.

For now I will focus primarily on the customer-facing part of the system, prototyping manly with HTML-based interfaces. Working this way, I should be able to test fairly easily. As I build and upload new interface ideas, I can send links to prospective users. I can get feedback manually or incorporate a basic survey into each prototype. Rougher ideas can be paper-prototyped and tested within the SVA studio, as well as with friends. I will of course focus on existing glasses wearers as my initial test groups.

The basic process we defined regarding eyewear design moves from coarse decision to more refined ones (it is a design process, after all), but it begins by dividing users into two main groups: sport and fashion. I am still debating whether to begin this early in process, but thinking along these lines does allow me more options for user input, as fashion-focused users are generally more interested in front-facing appearance while sport users tend toward features and function. Fit is important in both camps, but again, the specific needs of each user camp weigh more heavily on some aspects than others. As I define these paths with my eyewear contact I will incorporate them into my user testing.

Failed Predictions from Back to the Future

I watched Back to the Future two weeks ago—all of them, even the crappy third one set in the Old West. It was a quiet Friday perfect for some procrastination. I have always loved those movies and hold a special, shameful fondness for Part II, set largely in an imagined 2015. With that date approaching, I figured this is as arbitrarily as good a moment as any to point out some of the predictions Zemeckis et al made in the second film in the series, Back to the Future, Part II.

Hoverboards. I remember these being a huge topic of conversation when the movie came out. Apparently a few false rumors had been leaked that the only barrier to them being sold in 1990 were the safety concerns of various parent groups. They were, and are, technically possible, by floating superconductors over magnets. In fact, the Shainghai Maglev Train uses this very technology to transport passengers every day, but it requires a specially designed track and train, exorbitant amours of energy, and sophisticated cooling systems to run. I also never quite understood how normal, non-hovering sneakers could push the boards forward.

Jaws 19. This 3d hologram trailer was intended to show an analog to the apocryphal reaction to the 1895 film Arrival of a Train at La Ciotat. While the Jaws franchise is hopefully dead, I could see Sharknado in hyper 3D one day. Or maybe Pirhanna 4DD: Part II?

Power Laces. Apparently this is happening, more or less.

De/ReHydrated Pizza. While the bag of Trader Joe’s Inner Peas I’m snacking on while writing this would suggest that freeze-dried foods are common in the 21st century, the writers of BTTF clearly failed to predict the Obesity Epidemic and Slow Food Movement. Sadly, most convenience food isn’t nearly as visually appealing. I also want a bacchanalian supply of fresh fruit that retracts from my ceiling.

There are actually many parts of the movie that are completely spot on, give or take a few years. There will likely be some sort of personal display tech in place soon. Existing drone technology could easily be used to walk dogs. Fingerprint scanners and similar biometric sensors can unlock an iPhone, and that technology could be extended to other transactions as well.

But there are a few glaring problems with other predictions within the film. In a scene where Marty is asked to “thumb a hundred bucks” as a donation to the Clock Tower fund, the assumption is that he, having just traveled from 1985, will be startled both by the mean of transaction (fingerprint) and the value of money in the future. But for this to work, the inflation rate would have to be nearly 50x what it has currently been over the past 30 years. Assuming a $1 donation in 1985 would have been adequate (if a bit high), that same donation would only be worth about $2.10 in 2012 dollars. It was the start of the ‘Go-Go 90s’ though, and they may have been overzealous about the growth rate of the US economy.

Fashion is as problematic in BTTF as in most sci-fi of the day. It is based on the assumption that people living in the depicted world are going to view that world through the same criteria as we, the outside viewers, do. As technological development is the primary difference between now and the foreseen future, that is the lens through which the narrative takes place, and is shown as the most important part of the predicted society. As such, it permeates the narrative culture so thoroughly that even the clothes people wear are subject entirely to this tech treatment. Materials, colors, and textures, not to mention norms and habits (such as turned-out pockets) are all a product of the perceived tech gap, not the arbitrary choices made by the fashion community of the day, though maybe that is a hopeful viewpoint.

Communication is another glaring failure in the prediction model of BTTF. At the dinner scene, while eating the rehydrated pizza, 2015 Marty receives a call from Needles (played by Flea). This call comes into some singular communication channel in the house, as both kids (both played by Michael J. Fox) tell Marty that the call is for him. The writers clearly missed the advent of cell phones and personal communication channels, assuming the land telephone line model prevalent in the late 1980s would still be in place 30 years later. They show too optimistic a view on presently controversial technologies, like wearable displays (Google Glass), and have apparently missed the smartphone altogether. The distracted teens, completely wrapped up in their own digital experiences, are pretty apt though.

Within the failed communication prediction is an assumption that the fax machine would play a role in 2015. With ubiquitous wall-mounted and wearable displays, voice activated robots, and biometric data authentication, why the world would need to print messages on paper is beyond me. This feels primarily like an effort to connect with the audience of the day, getting less mired in extrapolation and providing a mechanism for plot development.

Back to the Future, Part II makes a mistake common to future predictions. Namely, it assumes that 30 years is enough time for major technological development to change infrastructure, habits, and fashion, but not enough to affect core behaviors and rituals.

Sliders

Last week I went to the 3DPrintshow in Chelsea. I don’t want this project to be inherently tied to any particular manufacturing technology, and I want in particular to steer clear of the 3D print bandwagon. But the community around additive manufacturing is driving the push toward mass customization more than any other, so I went to the show hoping to find new technologies for form creation and new interfaces for end-user customization. Both fronts proved fruitful to varying degrees.

I caught the talk given by Assa Ashuach on “User Informed Objects.” He has some great thoughts on the subject of user data driving product form, and has been working in this area for years. His company, Digital Forming, has built a tool that allows designers to upload and parameterize product designs for manipulation and customization. They have a marketplace with a handful of designs already available for customization and printing via various services, like shapeways and i.materialise.

I greatly commend their efforts to move beyond the simplicity of some of the Shapeways co-creation tools, while making the complex formal manipulation offered by companies like Nervous System more available to independent designers and non-coders. Yet all of the tools depend on an end-user being able to determine for himself what form is best. This dependency defines a deep limitation in present notions on mass-customization.

The designer’s role is not arbitrary. The creation of form in response to context is the reason the design profession exists, and it is not one easily replaced with basic algorithms. Giving a user an on-screen slider with which to change and mangle a form, even if that mangling is within imposed limits, does not do justice to the role of design. Nor does it likely result in better products, just more varied ones.

Competitor Assessment

These are some other projects in my thesis space. I will add to this list as appropriate.

https://www.kickstarter.com/projects/723819776/meshup-mashup-for-meshes

http://www.uformia.com/products

http://meshu.io/

http://n-e-r-v-o-u-s.com/

http://www.shapeways.com/creator/?li=nav

http://lab.modecollective.nu/

http://www.grasshopper3d.com/

http://www.nytimes.com/2013/10/10/garden/light-up-the-cigars-its-a-chair.html?_r=0

http://endlessforms.com/

http://prestobox.com/

Mass Customization Spectrum

This shows a 2-axis spectrum of user input and feedback for 3d geometry creation systems.

Prototype Plan

I plan to build out two prototypes in the next 3 weeks. The first is a continuation of the work I’ve been doing with evolutionary algorithms. I plan to build out both the “DNA Provider” and end user sides as a pair of web-based applications. They are outlined below.

“DNA Provider”:

This is a direct iteration of the last prototype I developed. I will continue building out a focused 3d modeling tool, which in this case will be used to make and record geometry data for cup designs. The designs will in response to various stimuli, such as images and words.

Timeline (next 3 weeks):

2/10 - Refine the existing modeler I have already built. Allow for more variation in design.

2/17 - Build in functionality to record the geometry being created. This will be uploaded to a server in a standardized, comparable format. Build functionality to connect user accounts and stimuli.

2/24 - Test the modeler with ID users. Establish ideal use cases.

Timeline (next 6 weeks):

3/3 - Finalize stimuli list. Acquire content and build into server database.

3/10 - Finalize page layout and visual design. Test with prospective user set.

3/17 - Test prototype, including data generated.

Cup Creator:

This is the other side of the evolutionary algorithm prototype. It aims to match user input to the form/stimuli database created with the “DNA Provider” prototype. This application will be much simpler to implement, as the form data will be standardized and simplified.

Timeline (3 weeks):

2/10 - Sketch page design concepts. Consider IA and user flow. Establish a working list of possible stimuli at varying degrees of literal relation.

2/17 - Refine stimuli list.

2/24 - Build base system in tandem with DNA Provider. Test and determine ideal use cases.

Timeline (6 weeks):

3/3 - Finalize and implement stimuli. This data should be similar or identical to that used for “DNA” capture.

3/10 - Finalize page layout and design. Test.

3/17 - Test system. This will be preliminary until more DNA data is acquired through the first system.

ID Habits Die Hard, On "Breaking the Curve"

I was deeply inspired after reading Breaking the Curve (thanks Eric, for sending it my way). I have used and taught CAID software for years—mainly Solidworks and Rhino—and I have many discussions about the relative merits of many applications with colleagues and students. While most of our arguments centered around the debate over Parametric vs. Direct as a modeling and interface paradigm, there has been little discussion in ID around abandoning the NURBS surface as the principle (sole?) representation of 3D geometry. In pursuit of the elusive (and deeply misunderstood) Class-A surface, it seems that NURBS are the only construct available to the designer. Of course, the very notion of surface continuity is part of the NURBS definition, so it may be impossible to decouple these practices. But still, I have worked with engineers who won’t touch a Rhino file because they somehow feel it lacks mathematical purity. Personally, I think it’s because Rhino is priced at under $5K, but that’s a different debate.

For the past four years I taught T-Splines and SubDivision Surface techniques as part of my surfacing class at Pratt Institute. As a method to explore smooth, organic form quickly, SubDs are greatly preferable to the paper-sheet manipulation and planning that comes with NURBS surface modeling. And with tools like the tsElements plugin for Solidworks, there was almost some continuity between modeling paradigms. Yet, like so many tools, the seemingly simple workflows allowed by SubD modeling belies a much more complex set of concepts that are very difficult for most designers (a surprisingly non-technical group) to grasp. My students regularly contorted their designs into convoluted messes of control polygons that would not allow downstream modification, which led to inevitable frustration with and mistrust of the tool. Or maybe I wasn’t explaining it well enough.

Now I look at the rise of tools like Z-Brush and Mudbox, which happily toss the NURBS paradigm altogether in favor of the *much* more intuitive manipulation of mesh vertices. I also see that there is almost no uptake of such tools in any of the studios or schools I am familiar with. Or if mesh modeling is entertained as part of the workflow it is relegated to the early, completely conceptual phases, and its value is always questioned in the face of ultimately having to switch over to NURBS-based representation for engineering. As such, designers often struggle with difficult and non-intuitive tools at the expense of perceived engineering costs. Yet, the final digital output of any product will always be a mesh, whether it for rendering, analysis, 3D printing, or CAM tool path generation. I am left to wonder why we don’t work in final materials.

Much of the industry trends exist rightly due to the poor surface quality traditionally offered by mesh-based technologies, as well as difficulties in editing such structures. Yet, computing power has increased and better programming exists to mitigate much of these problems. The T-Splines plugin for Rhino attempts to extend standard retopology techniques to the point where NURBS-quality surfaces can be pulled from a dense mesh. It is technically possible to make meshes and NURBS play well with some simple conversion, though no one has integrated such a paradigm into a modeler...yet.

Cup Creator Prototype

I made this prototype a couple weeks ago and have yet to really delve into the thinking behind it. It goes in tandem with a variation on the prototype I presented at the end of last semester, where I explored using basic evolutionary algorithms to iterate and develop cup forms. The challenge with using evolutionary algorithms, which is very much the challenge with creating good computer-generated forms generally, is in codifying form into data that is computable. There have been many attempts to codify “good” form making for human designers—this is the essence of design education—and no base theory, from the highly structured Bauhaus curriculum to more implicit ideas put forth by Charles and Ray Eames to the 3D Abstraction courses developed at Pratt Institute, has served as a complete and coherent blueprint for creating and evaluating form.

While conjecture does aid in developing general theories about the purpose and role of design that appear to last longer than a current stylistic trend, no specific aesthetic pushed by any particular practitioner seems to fuel the zeitgeist for more than a few fashion cycles. Beauty, it would appear, is in the eye of the beholder, or at least the eye of the most prominent, and ever changing, possessor of the dominating opinion on what is trendy at a given moment.

So, how could computers possibly be used to generate good, acceptable forms? The short answer is that they, on their own, cannot. Inasmuch as human emotion and judgement is a highly complex process marked by unpredictability and inconsistency, there will likely not be any graceful and complete systems that mimic human behavior developed. This is a core tenet of the argument behind “Brute Force Artificial Intelligence,” which views such computer-made decisions as the result not of complex and graceful relationships, but rather the result of extremely large data sets and massive computational muscle. This is a core function of computer science in general, which often seeks to separate the concept of computation from the often more conceptually complex notions posited by traditional, “pure” math.

But back to form generation and my prototype. In order to create a system that could iterate over cup designs, I needed to have a computable understanding of what cups are. If I were better at programming image recognition and processing statistics, I would have built a system that functions not unlike Google Search (clearly a simple problem), in which I could direct a program to traverse my chosen field to find connections between form and context. In the case of this prototype, the forms would be coffee cup and tableware designs and the context would be images, language, setting, and history. to build such a system I would have to incorporate image and pattern recognition, natural language processing, statistical analysis, and probably a few dozen other highly specialized and disparate skill sets. That endeavor was a bit out of my budget.

I can, however, kludge together a crude 3D modeling application that can run in a web browser. Inspired by the methods of Pandora and the Music Genome Project, and well as Google’s Image Search, I took a stab at mocking up an application that can record 3D data. The prototype allows a designer to create a cup form inspired by seemingly ancillary criteria, in this case placeholder images. The form data is attached to the image and retained in a database. My plan is to refine, deploy, and invite designers to use this prototype. I will compare the data I acquire and look for commonalities and patterns. Once I have enough input information connecting form and cups, I will deploy an application that aims to build custom cups for customers, using the same image criteria as the means for iteration.

Prototype Roadmap

Explored: I have looked at evolutionary algorithms for form iteration. I need to refine the means of determining DNA to pass on to each subsequent generation, as well as devise a good means for creating mating pools. I found with an early survey that people enjoy choosing between image pairs as a way to construct meaning.

Unexplored: Other means for devising and exploring form. I would like to play with creating simulated living systems and employ growth algorithms as a medium for form iteration. I would also like to play with the degrees of user involvement in growing those forms, from the role of ‘prime mover’ to one more active and similar to cultivation. Employing personal data over time is of interest as well, as a passive means to possibly determine true user desire in a form.

Roadmap:

Build branch sconce organism, exploring both simulated organisms and the prime mover user role. This prototype will also help me learn more about coding computational geometry and complex server-side applications. Deploy this to the web using the Shapeways API. Take marketplace activity as a relative measure of success.

Refine DNA acquisition code. Make it more feature complete, allowing more formal complexity and design options. Wire up the backend and deploy the application. Test this with an invited pool of designer users, as well as novice form makers.

Use the data gleaned from the DNA prototype to refine the customer experience for creating mating pools. Try this with both the direct, form-selection model and the abstracted image choice model. Run A/B tests to determine which produces better forms for users.

Design an application that serves to test actively participating in cultivating an organism or system over time with the intent of indirectly creating a form. This prototype will likely feel very much like a game. Test to find out interaction success based on how much time users spend cultivating the system, and how much pleasure they get from doing so. Test formal success based on user interviews or, if possible, direct revenue.

Create a system that uses indirect yet frequent data acquisition to modify and iterate form. This prototype may give much less immediate feedback in order to achieve a more subtly connected final form. Some data acquisition object will likely be employed, and that “helper device” will also require its own design choices.

Create a spectrum on which all of these experiments can exist. This is the likely form of the thesis; more of a documented exploration than decisive problem solution or conclusion. Crap, I guess it is speculative design.

Fresh Start Brainstorming

Concept Continuation: As a continuation of my original prototype, I wanted to explore different decision-making criteria. My original concept relied on a direct, conscious preference of one form over another, but this could easily ignore important decision making criteria. Choosing a mating pool this way is not unlike the difference between a multiple choice versus long-form exam or survey. It may be more convenient, but if the available choices happen to not include choices relevant to a user, they are essentially moot. The next iteration of the original, prototyped concept would seek to build a more complex 'DNA' for form and object. It would take into account deeper contextual information, with the goal of building a better connection to that user's needs and desires. Building that DNA is a challenge, however, and a few thoughts on Artificial Intelligence creation may help. Establishing a graceful, balanced, top-down set of DNA criteria is complex enough to be considered impossible. It would require many months of interviews, synthesis, and correlation, just to establish basic algorithms for initial testing. Using a more 'brute force' creation system would be more appropriate, but a secondary system for data acquisition would also need to be build. An inspiration here is Google, which, when challenged with creating a database around image tagging, employed simple game mechanics to essentially trick thousands of users into providing that data. A similar mechanism could be used in this case, focused on either object creation or description. The creation version could be aimed at industrial designers; they could be given a focused modeling tool and tasked with designing to a word, phrase, or image. The modeling program would record the 3d geometry as the DNA of the stimulus and later apply it to iterating over new forms. New Concept: I am also interested in other means for creating form, other than genetic algorithm and selection refinement. Systems that allow for direct creation, albeit with indirect means, might also prove a fruitful direction. Deeper data sets could be acquired, possibly through sensor systems and 'helper' products. But playing with a system might also work. Here I am thinking about the fun people have gardening, or playing games like The Sims. I would like to explore giving a user a tool that allows for product and from cultivation over time, within some set of constraints. This might be best realized as some sort of video game. I am most interested in systems similar to gardening and agriculture, and the practice of arborsmithing comes to mind.

Prototype Reflection and Evaluation

The “final” prototype, made in Keynote to demonstrate UI:

Pre-final prototype, where users were asked to select surfaces to be used in a simulated mating pool to generate more iterations via a basic evolutionary algorithm:

Reflecting on last semester’s development and prototyping process, I have come to following conclusions regarding the questions:

What was the strongest component of your prototype?

It was ambitious, maybe too much so. I had planned for it to be more or less functional, at least in terms of an interface prototype, with full drag and drop functions and animations. I used Adobe Flash, which was a debatable direction, but more on that choice in the next section. My hope was to simulate the user-facing parts of the ideas I was working with, and leave the backend intelligence for a later iteration. I also put together a pretty good random coffee cup generator using Rhino.

The earlier prototype was, I feel, more successful. It lacked a coherent purpose, as I was asking users to choose between utterly abstract surface variations, but the lineage and selection pool were more clear. It also worked—in its way.

What was the weakest component of your prototype?

That the final failed to actually function, and I was forced to cobble together a last minute sketch in Keynote. In retrospect, I should not have tried to build as working a version, and should have avoided Flash altogether (it really does suck). The prototype I presented was not a clear explanation of my thinking and it absolutely lacked any vestige of good design. I need to explore some of those screen-based interfaces as static or minimally moving components, and make a better effort at getting a design language in place. But that is an area I always struggle with.

What are the areas in your thesis concept to further explore for: a) interaction, b) design, c) technical?

Interaction - I want to play with contexts for interaction. I am starting to think about systems for mass-customization as existing along various spectra. I’d like to explore various points along that spectrum. Right now, it looks a bit like a 2-axis graph, with active involvement in the creation process plotted against time to deliver. I plan to try at least one iteration in each of these quadrants, as well as exploring new structures for organizing my ideas. Specific explorations may exist in screen-based, physical, or hybrid interaction spaces. I will determine these details as further research dictates.

Design - Not sure yet, though it is not a portion I want to ignore for long. As I explore my ideas and flesh out a few directions, I imagine design directions will emerge as context does. But I am ultimately thinking in terms of broad frameworks, so specific aesthetic details may not be necessary to explore.

Technical - I very much want this to work. I am presently learning some of the core computer science topics centered around 3d object creation and manipulation. I plan to develop primarily with a web context in mind, so I am looking at Three.js in particular. I enjoy writing Python, and it has great list comprehension, so I will likely use that for any server-side scripting I do. If necessary, I will explore C++, probably via openFrameworks, or Objective-C and iOS development as well. But once the core mathematical understanding is established—specifically around 4x4 matrix manipulation, much of the work is done.

What are existing attributes to further refine and iterate for your thesis concept?

I primarily want to explore the breadth of the interaction space available for mass-customization. I specific prototypes I’d like to build within a few of these spaces. I plan to iterate in each space over the next 6-8 weeks.

What new areas have you not yet explored?

I have been looking mostly at systems that involve some conscious choice, coupled with an evolutionary algorithm to produce each successive iteration. I would like to play with using larger sets of user data, possibly recording information over time and using it to establish new designs. I would also like to explore game-like systems, encouraging the user to actively create a design over time with indirect controls. I am also curious to see what interactions in physical space look like compared to screen-based ones. And I need to further investigate my original idea of coupling user choice with algorithmic iteration.

In thinking about the user’s experience what phases have you overly focused on? What parts of the experience have gone unexplored?

Interestingly, on both counts, the choice mechanism.

Mass-Customization/Co-Creation/Algorithmic-Iteration/Other-Hyphenated-Idea — Criteria for Success (and Failure)

User and Design Criteria

It should:

provide unique design options

provide good design options

provide individualized and meaningful design options

be delightful to use, either through process or output

provide coherent feedback throughout the creation process

It should not:

support existing disposable product cultural trends

occupy a consumer space already served by one-off and bespoke manufacture

replicate existing designs

make use of arbitrary data

make arbitrary connections between data and form

Personal Criteria

I would like it to:

take advantage of new manufacturing methods and technology

be accessible at multiple price points

serve as inspiration to traditional product designers

exemplify a new process for product design and object making

be extensible

provide better design solutions than are available through traditional means

work

I hope it does not:

replicate existing computational geometry creation trends

depend on trivial product choices

be entirely theoretical

be encapsulated entirely in whatever example product I develop for the presentation

Summary - Thesis Development - Fall 2013

This post will eventually serve as the principle summary of my thesis subject and exploration from Thesis Development, Fall 2013.

Rant and Yammer @falets-blog - Tumblr Blog | Tumgag