Jelly is a web development environment that works to close the gap between bloggers and programmers. The software, which is open-source, lives on the server of a user who maintains complete control over the data. Technically, it strives to break down the seemingly insurmountable wall of interactive web development. It does so by giving users a simple in-browser environment for creating complex websites, as well as ways to store, access and share their data in a way that doesn't feel like working with a database.

Audience
Iteratively:

1) ITP Student - very technically capable, enough experience with programming to understand what Jelly is wrapping around.

2) My mother - technically capable, but with no programming experience.

Implementation
Jelly

Web Development Toolkit

At a simple level, I'm working on a website development toolkit. It's a single file, making for an easy and even web-based set up,
after which a users web address becomes a website sculpting environment via the browser. The user can work with a library of existing types by dragging them into his/her pages, the user can extend types to support new properties and functionality as it comes up, the user can create types from scratch and work with them, and the user can template the display of content. This is primarily just an "ajax" web-based interface and realbasic like tag language that wraps around database control, but the near-instant browser-based malleability of database structures has a few heavy implications:

1. Fast prototyping: The time to develop the data infrastructure of, for example, any itp web project is reduced to about a single day, shifting the focus of web development entirely on the interface, or to a position that interface design is done parallel with and influences infrastructure design. This is the humblest of my goals of my thesis -- That the students can use my project in order to sketch and develop their social network ideas, in the same manner that they use arduino to work on their human computer interface ideas.

2. Inhabitance: web service, its structure, its interface, its logic, can be potentially mutable by any user of the website, bounded only by permissions settings, not possibility. As a website developer, I might not choose to let every user cumulatively design the structure of my website, but I have to make that choice. As a result, the general expectations of a user's relationship with a web service might become significantly different. Right now, as a user, we are expected to participate in a video web service community by uploading videos, uploading comments, or uploading tags, and that is exactly it. With Jelly established, we might even be expected to appropriate the structure for ourselves, with several particular groups of users sculpting several interface and feature "takes" on the same video web service, for example.

Sharing

While a browser-run well-developed web development toolkit can make a phenomenal difference, the concept of rapid application development is hardly new. What makes Jelly interesting as a thesis project is its distributed architecture. Jelly structures an internet culture in which data is allowed to be autonomously owned, and web services are simply interfaces to distributedly stored data. For example, as a Jelly member, participation in a Jelly website consists of making references between the website and myself. In other words, when I upload a video to JellyYoutube, I essentially subscribe myself to support the JellyYoutube interface service, and upload a video to myself. The JellyYoutube service itself pulls and caches data from me and all its members, rather than housing the data itself. This is an exact inversion of the web service industry, but it has some interesting implications.

1. Ownership: The user owns his or her existence. A user's data doesn't exist only within the walls or APIs of his or her web services, it exists external to these services, and interacts with them. This gives the user the right to control privacy, propagation, copyright, creative commons license, as well as license to join and leave services without erasing him or herself. Jelly would guarantee creative commons licensability at the data level, as well as implementing inherent privacy and propagation rules.

2. Collaborative Service: If my "friend" in Jelly has developed (or placed) a new structure on his or her website, say a recipe, my library of friends' types will include that structure. I can use it on my page to throw down recipes on my own website, and my site instantly has the capability my friends' recipes as well. Likewise, my friend's site will have the capability to display my recipes. Extrapolate this pattern, and the hardware requirements of a youtube like interface get cheaper per user as it gains more jelly users, because the service is powered by the users. If this isn't quite clear, the analogy of a delicious tag is very close. The tag just exists for one person at some point, but as many users adopt a particular tag, it becomes more relevant to each of the users. Notably, there is very little effort in placing the first tag down, it just happens to be relevant or not to a history of users thereafter.

3. Multiplicity: The abstraction of data from a particular instantiation (my site, my friends site, my friends friends site, for example), means that any jelly user's data can fit a variety of interfaces. Each user or group of users can tweak and adopt a particular interface for working with data, and each interface I'm linked to will still be able to reference my data in its own context. To some extent, this simply means that Pandora , iLike, etc. might all exist as particular views of their members's data rather than particular containers. But it also facilitates mashup services.

4. Identity: As web hosting costs continue to decrease, and as Jelly can partner with and become preinstalled on webhosts, there might become a critical mass of Jelly users with their own websites. At that point, identity becomes quite awesome - My website will by necessity be able to define me as all of the interfaces I've decided are relevant, my participation within all of those services, and access levels to all my data, and an iteration of friends' participation in similar services. This identity will exist on my site, external to the web services themselves, and in my control. I imagine this as an interesting take on social network identity, and a direction that Facebook Applications has already opened.