Continuing discussion of the new Sharendipity UI, which was started here, now we turn to the new behavior editor.

The behavior editor is where a user controls component or application logic. This can range from simple rules to complicated programming. Our goal was to make the UI intuitive for non-programmers, but powerful enough for experienced programmers.

Previously, our UI was based on a tree-structure, and we presented all available options at each node in the tree, producing entries like this:

This UI included pull-down menus on each element that produced a multi-tiered menu, and a + menu on the right side that allowed addition or subtraction of other terms. The UI got the job done, but was intimidating and clunky. It didn’t give the user any indication of what to do, or whether a given selection made sense.

Our new behavior editor was inspired in part by Scratch from MIT, which in turn was inspired by Boxer.

The new UI is completely drag and drop. Actions, objects, attributes, and functions are presented in a navigator and dragged into the behavior editor. The action above now looks like this:

If I want to change the right-hand side from “0″ to some other value, say a copy of another object’s attribute, I simply drag in that attribute:

1. Initially, I can type in a value for orientation.
   
2. Instead, I’m dragging over the circle’s orientation attribute.
   
3. Now my orientation is set equal to the circle’s orientation.
   

But what if I want to add something to the right hand side? Previously the + menu provided access to addition or subtraction terms. In the new paradigm, I select a math function from the navigator:

And simply drag it onto the value:

1. Drag the plus function and drop on circle’s orientation.
   
2. The existing value, circle’s orientation becomes the first argument.
   

The comprehensive set of mathematical functions allows any equation to be created.

The logic for boolean operations is similar. Conditional statements are formed by dragging over logic blocks.

Again, a comprehensive set of boolean operations allow creation of arbitrary logic.

Notice that the boolean functions are displayed with a diamond shape that fits into the IF and and statements. This shape conveys to the user visually where a given function or attribute can be dragged.

The same shape is used for attributes. The boolean attributes below, such as ignore_collisions, have the same diamond shape.

The end result is an editor that provides comprehensive functionality in a straightforward drag and drop interface.

Give it a try and let us know what you think! If you’re an alpha user, you can examine the logic from popular games like Filla. If you’re not an alpha user, send an e-mail to alpha at sharendipity dot com and let us know a little bit about yourself.

We’ve just released a completely revamped user interface for Sharendipity! This project has been underway for the last month or so, driven by internal and external customer feedback. Our overriding goal was to make the software approachable and intuitive for both consumers and creators.

The slide-out galleries at the top and bottom of the screen? Gone. The radial menus? Gone. The complicated tree-based behavior editor? Gone.

Instead, we now have a paradigm based on characters that guide the user through the development process. These characters appear at the bottom of the screen and can easily be toggled on and off with the escape key. (Note that the graphics are temporary and may change.)

The director (currently a professor) guides the user through management of high-level applications and scenes.

The construction worker provides access to the basic building tools for creating circles, lines, joints, and other content.

The librarian provides access to the user’s collection of assets (the gallery) for the current application.

And on the right side of the screen, separated from the other characters, the Explorer acts as a gateway to the components and applications created by the community.

Clicking on these characters produces a menu or window corresponding to the character. For example, clicking on the explorer produces the search window:

(If you’ve used Sharendipity, you’ll see that the Search window is completely revised as well, providing access to more search results in a better organized list.)

Similarly, clicking on the construction worker produces the tool menu:

In the near future, these characters will also guide the user using word or thought bubbles - providing an interactive tutorial for new users.

A future post will explore the new Behavior window.

We would love to hear what you think about our new UI. Post a comment, or better yet give the tools a try and let us know what you think.

We recently issued a new release of the Sharendipity platform that was aimed at improving launch performance. One of the issues that we addressed was the scripting engine that allows advanced users to extend the core functionality of the platform.

You might think that the underlying scripting engine is only important to the authors of shared assets in Sharendipity. The reality is that the wrong scripting engine can provide a very negative impression of application performance to any user.

Originally we used the Jython project to provide scripting using the Python language. The functionality was great. It was even fast. Despite this, there were a few big problems.

Jython is large. The download size for Jython alone was nearly 1.2MB. The result of this is that the user’s first experience when launching our applet takes significantly longer, directly affecting the percentage of users that are willing to sit through the download.

This wasn’t the biggest problem though. Our number one issue was the initialization time. On many users’ machines this was commonly around 10-15 seconds. When a user launches an application in Sharendipity, it may require the use of scripts before doing anything else. We needed the application to launch and run immediately and this just wasn’t possible with Jython.

Our most recent release changed our underlying scripting engine to use the Rhino JavaScript implementation. Rhino fixes every single issue that we had with Jython.

The Rhino developers understand the importance of a small footprint. Rhino provides a very easy way to reduce the download size to as small as 204KB, or about 20% of the size of Jython. There is no initialization time for the Rhino engine either, so there is no pause when loading an application in Sharendpity.

The smaller download and lack of initialization are a huge win for us already. There’s also something else that developers might not think about when choosing a scripting engine, and that’s portability.

We’re still in Alpha mode, so we have enough flexibility to change our scripting implementation. JavaScript (or ECMAScript), is the only scripting language that was really an option when creating a Rich Internet Application. This is what ActionScript, Flash’s language, is based on, and Silverlight supports it as well (in some respect, at least). Furthermore, just about every web developer in the world knows it.

We’re trying to strike a balance between the demands of our power users and the ability for our casual users to launch existing content very quickly. We’d love to hear your feedback on walking this tight line!

There is a terrific article by Marc Prensky in the March issue of Edutopia titled “Programming: The New Literacy”. Marc makes the case that literacy will soon be defined not just by reading and writing skills, but also by programming skills.

He reminds us of a level of programming everyone is already doing with our phones and remote controls. What’s most interesting is that he expects everyone to graduate from this type of menu-driven programming to a point where many of us will be using scripting languages, Flash, and/or piecing together open source software to meet a specific need.

“As the highly literate adult of today might pen a witty birthday card note for a young niece or nephew, the highly literate adult of tomorrow might program the child a game. And though today’s highly literate person may enjoy a sophisticated novel or nonfiction book on a plane or train ride, tomorrow’s highly literate person may prefer to change, by programming, whatever story or other media he or she is interacting with to suit individual preferences, and might then, with a little more programming, distribute those changes to the world.”

Marc isn’t alone. The Python community has rallied around Guido van Rossum’s beliefs that everyone should learn to program.

We share Marc’s vision in terms of the end goal. But I think we differ in how we’re going to get there. Rather than educating everyone on programming, we believe the best way to get to this form of literacy is fix the tools. If tools are available to create and distribute software without the need to program, then creativity can be harnessed more effectively. Surround that with a community capable of sharing ideas and software components, and now creativity can actually be accelerated.

Do you share Marc’s vision for literacy?

Every introductory course in software engineering talks about object-oriented software design and the benefits of code reuse. I still remember the lecture from my first programming class. Looking back I realize that the instructor failed to address why, in practice, software is rarely reused. I believe that the reason that code reuse is not more prevalent has to do with the fact that at the end of the day, it is the code itself that is being re-used, rather than higher level abstractions. Instead of writing code that adheres to a specification for reusable code, engineers are copying and pasting code snippets.

To be clear, there is a lot of code reuse going on out there. Open Source Software is successful because largely because of reusing code. It is not my contention that it doesn’t happen at all, only that it could happen a lot more.

The problem is that code reuse doesn’t just happen naturally. Reuse must be a core element of the design to be made possible. It’s true that software libraries can be intelligently constructed with well thought out interfaces that correctly hide the parts of the implementation that shouldn’t be visible. However, it takes a seasoned programmer to implement this in an intuitive fashion. Even if you are the consumer of a well-designed library, there’s a pretty good chance that its interface is not going to be part of a standard for related libraries. So, if you wish to test out different implementations you need to modify your own code each and every time.

A good example of this is the many different XML libraries out there. Personally, I’ve experimented with Axis, Axis2, Woden, WSDL4J, WSIF, and Xerces in the past few weeks. Many of them have overlapping functionality but implement different interfaces and different usage models (I’ll refrain from sharing my hours of pain using all of them. Maybe that will be another topic for a later post). In order to test each one out, I had to create a new project in Eclipse, import the correct libraries, and modify my base template to use the different interfaces. With just about every package I tested I encountered a frustration and developed a lack of trust in the library that I was using. Granted, this lack of trust derives from what I consider some poorly designed libraries, but it was enough that we re-wrote some specific functionality because we didn’t have the control we needed with any of the individual packages.

Our experience was by no means unique. Jo Woodison documents several reasons for the elusive nature of code reuse. Those that are most relevant to our work include:

• Insufficient means to identify candidates for reuse in the development process
• Lack of available components to reuse
• Lack of flexibility in available components
• Lack of tools to assist with implementing a reuse strategy
• Lack of trust, the “not invented here” syndrome

Another reference to a really old (1969!) article titled “Mass Produced Software Components” by M.D. McIlroy touches on some of these same topics, notably the lack of a market for small software components where software components are analogous to nuts and bolts in the manufacturing industry. Granted, the nature of software has changed a bit since then, but this main thesis is still applicable, and we have yet to see a complete solution. Sharendipity is creating that solution for programmers as well as non-programmers by providing an easier way to build and share applications.

If we had a frequently asked questions page, undoubtedly, the top question would be, “What is Sharendipity?” Our network of friends and professional acquaintances have been pinging us with inquiries ever since we started this adventure. Well, Sharendipity is a lot of things. It always is to the founders.

It is still relatively early in our company’s life, which has led us to keep the lid on things a bit. However, we have begun reaching out to prospective advisors and investors, and have even presented a portion of our story at a Marquette University Symposium. The word is certainly getting out, and there has been strong interest in our signup list on the web page.

“What is Sharendipity,” you ask?

Sharendipity is our vision for a platform that allows people to express their creativity and share it with the world. It is a web-based community that turns users into creators, and gives anyone the resources they need to make the games, tools, and applications they’ve always wanted to make, but have never had the programming skills to make it happen.

Sharendipity lets even the non-programmers among us make the next cult-hit game and share it with anyone, or a garden scheduling database used to track seasonal schedules and seed inventory that a few thousand Wisconsin garden enthusiasts are dying to have made. In fact, we are providing the tools needed to build tens of thousands of niche applications that have yet to be made, but have demand from hundreds of thousands of individuals and organizations. It’s the ultimate platform for delivering the long tail of user generated applications.

We haven’t forgotten about the programmers (we are programmers!). Sharendipity is all about collaboration. Programmers will have the tools they need to build the advanced components in the system. Collectively, the community can take advantage of the expertise of its dynamic skill set. Artists, programmers, consumers, and designers will soon have the ability to share a single platform to make and use the applications they want to have.

Keep coming back. We’ll talk more about the technology and share some stories about life at a startup. We will soon provide access to the Sharendipity tools to a select group of people to gather feedback. If you are interested in participating, please let us know!