Spry Team

Hi spry:fans,

Thought I would pass along an update on where we are with the next version of Spry. We have some really good stuff in the works.

Kin has been working on the hornet's nest that is nested data sets. It's almost done. As we went through different use cases, it confirmed our fears that it was a beast and there are many ways to slay the beast, each with its pros and cons.

A small 'ferinstance': Because of the way we flatten, generating something like:

• Artist 1
  • album
  • album
  • album
• Artist 2
  • album
  • album

is very different in a data set way of thinking than:

Artist 1	album
Artist 1	album
Artist 1	album
Artist 2	album
Artist 2	album
Artist 2	album

What happens when you sort the 'album' column? It depends on how you break up the data. Right now, we are using the idea of Spry.Data.NestedDataSet which is a derived from a standard data set. We also have this idea of a 'join', or advanced flattening, where columns from the nested XML are appended to the parent data set.

The point is, there are many issues that needed to be solved for this to work in most (I hesitate to say 'all') scenarios. We will have good documentation when this comes out and samples as well. I will discuss it here before and after we release it.

We will also introduce the HTML data set. This data set will allow you to leverage regular HTML tables and structures as data sources. If we are flattening XML data into a table, then using existing tables is a small step for sprykind. But it's a giant leap in leveraging existing data and negating the need for XML. Anyone can create and update a table with ease. CSS can be used for filtering and extracting specific data. It's pretty darn cool.

We have been hard at work building new features, but working on Dreamweaver has taken priority recently and that has put us behind a bit.

Therefore, we are going to do a couple things:

We are going to preview our new functionality in mid-to-late March. We will post our new work to Labs as a preview. It won't be formally zipped, but we want to make it available to the community and we want early feedback on our new stuff, esp the nested data sets. We want to make sure our approach hold water with real world scenarios.

We are now planning on the next formal drop in last spring, probably in the May time frame. This will give us time to polish and vet the new features and get the samples and documentation in order.

We are also working on unobtrusive samples of Spry. We will demonstrate how to use Spry in a way that doesn't use custom attributes.We want to show that it can be done and how do it. We will also use the time to address the concerns of the standards and accessibility concerns that have been bubbling within the community for a bit now. We are serious about making Spry both simple and a proper way to code Ajax pages.

We have made some sizable changes to the way Effects work. They should be more uniform and controllable now. But it will require small changes to those pages with existing effects. These changes are small and only need to be taken if you want to update to the latest version. I will discuss this in more detail in a future post. We still have some time before this is released, so no need to worry now. Just a head's up...

And, I have to continue to bite my tongue on the new Dreamweaver/Spry features... We are talking about some eSeminars in the springtime to talk about Dreamweaver and to go over some of these new features I have mentioned here.

So that's it for this time. I don't mean to tease here, but I wanted to let you know what was happening and that we are indeed hard at work on the next version.

Thanks,

Don

Posted by Donald Booth at 08:48 AM | Permalink

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...

Posted by Donald Booth at 06:27 PM | Permalink | Comments (1)

Hey Spry:fans

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.

Thanks,

Don

Posted by Donald Booth at 07:32 PM | Permalink | Comments (6)

Hey Spry:fans,

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… Then we thought about Dreamweaver.

• Injecting markup wouldn’t be good. You want to see it and style it in Design View.
• Custom tags wouldn’t be good. There’s a learning curve and rendering issues.
• Lots of dependencies to track: no one likes that.
• Tough to support something that someone else writes. Difficult to maintain code parity.

So 2 things came out of this:

• There is room to innovate and simplify
• We should write our own framework

As we started to think about this and prototype things, our Spry tenets began to develop:

• Use what you know: Use HTML and CSS to markup and style the page. Avoid custom tags.
• Don’t inject markup. You can’t style it if you can’t see it.
• Keep it simple. Distill common functionality into an ‘easy to understand and use’ element. After all, computers are supposed to the hard stuff for us.
• Keep dependencies to a minimum.
• Make it page-centric. We saw that a lot of benefit to ajax was adding small pieces of advanced functionality to existing page. We aren’t creating an enterprise level application framework. We want to make HTML pages better.

With these ideas in mind, we started building the foundations of Spry.

In future posts, I will get into more details about how we got to custom attributes and more details behind the development of the framework.

Thanks,
Don

Posted by Donald Booth at 09:51 PM | Permalink | Comments (5)