Just another Adobe Blogs site

So last we left this question, we had decided to build a toolkit and had some guidelines in mind. These guidelines took into consideration the need of our users, the desire to make Ajax easier to implement and some ideas about markup.

Early on, we started with the data set/region idea. It seemed flexible and easy to build, once the basic concepts were understood. We liked the idea of data references. We didn’t want to needlessly invent things either. XPath was the obvious way to traverse XML files for the data set We tried to stick to conventions with naming data references, etc.

We started with using the class attribute to denote regions (It wasn’t called “Spry” yet….but I will call it such here.). We could do things like: <div class=”ds1″>. Spry would search through the classes and find those nodes with the data set name and know to process them. And then we could do things like <div class=”ajaxrepeat”> and Spry would know to loop over the data set.

But we quickly ran into issues. Loading the class attribute makes for tougher management of both CSS and Spry stuff. Then we thought about Dreamweaver users and the way that class management works. It could lead to trouble. We also were flummoxed when it got to things like if/then statements (today’s spry:if and spry:test). How to do that in a class or id attribute? We were overloading the class.

There were also some other issues to deal with. We tried to use XSL/XPath for real time transformation, but the browser support wasn’t there for it.

We tried using comments to contain the Spry logic, but Safari strips out comments when it loads the page.

We were a bit reluctant but we went to custom attributes. This gave us the freedom to do what we wanted to do. It also freed up the class for just CSS. It also made the page much easier to follow. The attribute stuck out and it was easy to look at the page and parse the flow, not only visually, but in the actual computation as well.

So we went with custom attributes. That let us get into the bulk of the Spry development, as we proceeded to our first release. We had many brainstorming sessions, debating the merits of one workflow over another, running into stumbling blocks and having to change things around. At this time, there were only 3 of us on the team, working on the side as we worked on Dreamweaver. We tried to identify the 80% cases for certain features and work flows.

It was nice to see our concepts come to life. We were leveraging CSS and HTML for template foundations and peppering them with attributes to kick off the Ajax functionality.

But now that we had our handy little attributes, we had new concerns, standards being the first of them. We were loath to break validation. We knew we could name space for validation concerns. The standards part was tougher. Was this innovation worth not being standards compliant? The pull between standards and innovation is a tough one. On one hand, as Adobe, we have a high standard to follow. As a small team trying to do something new, we needed room for flexibility.

The accessibility issue is tough too, not just for us but for all ajax frameworks. In a nutshell, the XML data doesn’t show up as part of the markup. This means that screen readers don;t have anything to read. Part of the trouble is that we are dependent on 3rd party applications for accessibility. Users will seek out the application with the best support, but knowing the state of these apps, it puts a burden on us to develop with accessibility high in mind.

We will cover these ideas in the near future.

But in our narrative, we had the basics of what would be Spry pretty well developed. Kin was heads down, cranking out code, building all the new functions needed for a robust toolkit, or at least the start of one. We still needed a name…

I thought I would periodically post replies to comments previously made.

Sammy asked: “You mentioned several of the teams goals, which all see worthwhile, especially from the developers’ who will use Spry point of view. Do you feel you’ve accomplished those goals, and if so, how?”
By goals, I take him to mean “easy to understand, easy to implement, clean code…”.

I would say that we are off to a really good start but still have room for improvement. I think we have found a good niche and I think our principles are sound. I think the region idea is unique in Ajax libraries and the attributes mirror common programming principles, making it feel like an extension of server side languages. But we have a ways to go. We have many new features we want to add and we can improve the way we code things. For example, we are making some changes to the way we code effects to make it easier to make cluster effects. But we only really know if we are on the right track if you tell us so, so let us know. Our pager sample is very cool, but we know that we should make it even easier to page data and create standard paging interfaces. We are working on that right now!

Ray is asking for API docs. They are written and we are trying to wrap up the editing so we can post them. I am really anxious to get them up, so as soon as they are ready, we will post them. Eventually, our docs will be ported to Live Docs so users can comment.

Colin is asking about the target audience for Spry and also about product integration. Our target audience is more on the designer side. The idea of using clean code, no custom tags and no injecting markup makes it easy for designers to know what the end result of the page is. Packaging the XML request into a simple, one line call, is pretty straightforward, even for those that aren’t JavaScript masters. There is a learning curve for Spry, no doubt, but we hope it’s easier to get started with than other frameworks. And since it is straight javascript, more advanced developers can leverage the work we have done and bend it to their will. As for product integration, we have stated that DW will support Spry. It’s too early for me to get into specifics, but it hopefully will make Spry development even easier. Some other parts of the company have integrated Spry in smaller ways, and I will discuss those when I can…

Phillip mentioned that our samples are too complicated, with too many examples of features. It makes it more difficult to get the big picture. I can see this. The accordion sample is quite guilty of this. But the samples are supposed to show off the features. In the Spry zip, we have a top level folder called ‘widgets’. These are the archetype copies of each widget: Just one example of the clean, basic widget. These might be better starting points. The samples are supposed to be more expository, but at the same time, we are trying to keep the samples clean, with minimal CSS. We have the demos for more real world, heavily styled examples.

And Bernd gives us thanks for the documentation and simple approach. We thank you for the kind words!

That’s it for this time. Let us know if there are features you would like to see, samples we should have. If you want to know the thinking behind some part of Spry, let us now.

I am going to have a couple themes running through my posts over the coming weeks and months.
The first is “Why Spry?”. In this, I will discuss how and why Spry came about, what our goals were and where we are going.
The second is “What’s Next?”. This will talk about some of the features and changes coming up in 1.5.

Today, we will start with “Why Spry?”

The Spry team is a small subset of the Dreamweaver team. In the fall of 2005, we were starting to think about the next set of new features. Ajax was making its name known and it was pretty obvious, as a web design tool, that we should look into it.

We started looking into the various frameworks that were available. After looking through a bunch, some themes developed:

Many had a lot of dependencies: many files had to be corralled to enable functionality.

It was hard to style: Markup was injected programmatically. It was hard to know what code ended up on you page.

It wasn’t easy. The learning curve was pretty steep.

But we didn’t want to make our own framework. We thought that maybe Dreamweaver could support a popular framework or two…

I decided it’s time to start blogging. I think there is enough action in the Spry world that this would be a good forum to make announcements, let you know what’s coming up and foster discussions about Spry and the Ajax community at large.

I’m not sure how often I will be posting; as often as I have something to say I suppose, but hopefully this can be another source of Spry info for our burgeoning community.

My first real piece of relevant info: We fixed a bug we found in Effects that causes elements to change positions in a poor manner. To fix this we uploaded a fixed version of SpryEffects.js. If you find that your effects aren’t working correctly, try downloading the new version from: http://labs.adobe.com/technologies/spry/includes/SpryEffects.js

This is the place to come to get the latest thoughts and announcements from the Spry team.

Of course the exciting news today is that we’re releasing the Spry framework. Spry was designed to help web designers (AKA front-end developers) be successful with Ajax. This is our first pass and we’ve focused on making it easier to retrieve and manage data without a page refresh. We’ve tried to keep the framework simple to use with the goal of making it feel like a natural extension to your existing workflows.

Please check out the Spry forum and Wiki to post questions and see what other people are doing with Spry. We’re looking forward to hearing your feedback.