13 Replies Latest reply: Jul 20, 2009 7:43 AM by flipone01 RSS

    Donald Booth question!

    @lexaka Community Member

      Donald Booth would like to ask you one question. I love SPRY, it allows me without much knowledge do nice things. But already in 2007, many asking the same questions, and reply to them though it has no mid-2009. You can find out whether in the near future ... or may already have their own test versions of LightBox, GreyBox or to use third-party developers?
      To my great regret, I moved recently, virtually all development LightBox, GreyBox, but either did not want to be friends with SPRY. There were also requests for the implementation of the capacity of drag-n-drop, and calendar. I would like to still learn about future plans ... What is worth waiting for and which in the near future is certainly not expected. You can simply voice dialing on the opportunities that await us in the future? Such blatant silence was put people on the unpleasant thoughts and hurt.


      If you are the approximate date ... before the end of this year or this year has nothing concrete to wait is not it?

        • 1. Re: Donald Booth question!
          Donald Booth Community Member

          Good morning,

          Thanks for writing.

          First note: We are working on Spry things. No one involved thought there would be 2 years between releases but time sure goes by quickly and we are as embarrassed as you are disappointed.

          We have been rethinking our widget model and are revamping how we write widgets, looking to make markup very flexible and more skinable. Kin was demoing something for me just yesterday. While an accordion will certainly not be a groundbreaking release, we are hoping that the new way of working will be inspiring.

          But still, we don't have a release date. I am pushing to preview things as soon as we can, so you can see what we are working on and to gather feedback.

          As to your other points, we have had many requests for a lightbox thing (or Sprybox as we call it). One reason we don't have one is that there are so many and we don't know where we would have anything new to offer yet. We do understand that people prefer to stick with one framework but there are so many other 'boxes' that we don't know if it is time well spent.

          Same with drag and drop. Not only are there many drag and drops out there, but they require some sort of server side functionality to track the drag order or just to do something with the reordered data. That gets beyond the goals of Spry: advanced functionality that is easy to set up and configure.

          With the time we have available, we want to make the best use of it and deliver features that our users want. If that is D&D, then we can do it. We count on our users to be vocal and let us know what they want and threads like this help us decide what to write.


          We don't have a road map and I don't see one in the near future. I know that is frustrating, esp when so many others have them. We are working with the resources we have and we are pulled in many directions.

          Kin is now tasked with doing some widget work and we are also working on cool widget tools that work with all frameworks. We are looking forward to being able to talk about that in the future. Company policy prevents me from discussing specifics and dates...grrrr.


          So again, I have to ask for patience, knowing that we are working on things and having to be in this cone of silence. We are thankful for our community and are grateful that you see the value in Spry and stick with it, considering there are so many other options.

          We will preview things as soon as we can. I wish I had more details for you.

          Thanks for writing and continuing the conversation.

          Donald Booth

          Adobe Spry Team

          • 2. Re: Donald Booth question!
            @lexaka Community Member
            It is unfortunate that information as they say in Russian "at the cat cried." 
            I never understood ... You mention about Sprybox. I understand that this opportunity will be realized? 
            I certainly did not head ADOBE But can not understand why a SPRY make such a secret facility? After all, he developed a laboratory ... where the slip of beta versions of other products. Why not start the production of beta versions for the masses? Moreover, many of the opportunities have already been implemented in other frameworks ... SPRY and distributed free of charge ... Apart from its inclusion in dreamweaver.

            I am confident that, whatever SPRY has been used as widely as possible, it must make available to the masses. This should be a weekly service releases Corrections found the user.

            For too long the game was delayed in the sensitive material. In doing so, forcing the already thin and not very extensive series of users SPRY.

            Believe me, it does not want to disappoint.
            • 3. Re: Donald Booth question!
              existdissolve Community Member

              Thanks for the update, Donald.  I know people get frustrated with silence and waiting, but I'm grateful to know that new things are coming.  I'm excited to see what you guys come up with--like everyone else, of course, I wish it was tomorrow


              On the "SpryBox" question, I understand where you're coming from--there are a TON of those out there.  One place I think Spry could make a big contribution, though, is in creating modals with the starting assumption that you're doing something MORE than simply displaying images/content/whatever apart from other content.  That is, I'd like to see something that makes modal form submissions (and similar functionality) as super-simple as a  Spry accordion.


              I think D&D is something that would be worth pursuing.  True enough, it's only really useful with the server-side hooks.  However, this is the one thing with Spry that I keep wishing was available, and I can see a bunch of really cool things that could be done by fusing drag-n-drop with the awesome data capabilities that Spry already provides.  At the very least, it would help Spry developers take user interface design to a whole new level, and not have to rely on mixing together frameworks just to fill in one missing peice.


              Another thing I'd like to see with Spry is a the fleshing out of a user interface library, something like Mocha UI or the others out there of the same ilk.  A lot of the pieces of this are already a part of the Spry framework, but a more seamless way to integrate the pieces into an application-focused arrangement (with resizable and auto-sizing panels, modals, etc.) would really take things to a whole new level.


              I could go on and on about the things I'd like to see from Spry--I think there's a lot of promise in the framework, and I believe the underlying philosophy is sound.

              • 4. Re: Donald Booth question!

                Thanks Donald!


                On the lightbox widget: as a developer (a particularly anal retentive one), having a 'Sprybox' would enable me to have markup and methods consistent with everything else I'm doing on the page with Spry, as opposed to introducing a second methodology / framework on the page that someone else (or myself six months later) has to understand.


                It's not ugly, per se, but it's not 'clean' either.


                And, as people evaluate different frameworks for use, their not likely to take a mix and match approach. Something as simple as not having a Lightbox widget may turn people off: "Oh, x, y and z are great but I really need to use lightboxes as well." It takes away from the simplicity of using Spry.


                A lightbox is one of those 'assumed' features at this point, think of it as an iPhone without MMS. Dealbreaker? Only for a few, but a nagging gripe for a lot of people.


                I don't know that your first release of one has to be groundbreaking or significantly differentiated from the others on the market. Let Spry be the differentiator, just get the basic feature in to satisfy the demand, and refine it later on.


                Not to be critical, I've been using Spry for some e-Learning applications and in certain regards it's been a lot more 508(c) friendly than Flash. Great work so far, keep it up.


                On that note: re-building CourseBuilder 100% in Spry would be a fantastic product.

                • 5. Re: Donald Booth question!
                  Arnout Kazemier Community Member

                  A reply to Donald Booth's post:


                  I'm glad to hear that you guys are working on Spry things again. 2 Years was / is long indeed, but as you might have noticed. The widgets that are released seems to be really stable. Sure things can always become better and new features could be added. But there are no major flaws currently in the data sets and widgets. So a small Hurray for that.


                  Personally I'm really exited to see what the new widget model is looking like, and can't wait to get to the "nitty gritty" with it. I know you cannot say much about it. But the widget dependencies, is Spry still going with the initial setup? 1 CSS, 1 JavaScript, or will there be a base widget source class / model what all widgets can depend on? (I wonder about this because I personally think a base class would be easier for third party developer to create widgets that follow the same Spry philosophy).


                  The current widget model is actually surprisingly skin able. But I think that most users do not think outside the box. They all see this ugly base skin that Spry provides and just change some values here and there and there done. For example, it wouldn't be so hard to transform a Spry Menu default CSS to make the menu bar look like the Adobe.com to menu. If there where more information about this matter I think people would fully understand the potential of it and will see that you can do much more if you extend the base markup to your needs + some custom CSS. But than again, I'm well aware of the fact that Spry is focused on first time AJAX users and easy implementation is the key of Spry's current success, but I do think some this could give un wanted and un needed restrictions to the users creativity. I have yet to see a see a "awsome skinned" widget.


                  I don't mean to sound harsh or anything, but if you say there are to many widgets already, than you could say the same thing about accordion widgets, collapsible panels, sliding panels, menu bars. There are also thousands of them. And yet they are a valuable asset of Spry. Not all these widgets follow the Spry philosophy and are easily integrated with Spry. What I would like to see from the SpryBox that is has the same functionality level as the Autosuggest widget, its easily plug able on a SpryData set. But can also be used with out SpryData sets, such functionality would be really valuable to have in my opinion. I think that a light box belongs in a basic widget collection of each framework. Its commonly used. I think its even more widely used than something like sliding panels.


                  Drag and drop is something I personally have been waiting a long time for. We already have data functionality in the framework, it would only be logical step to provide us with widgets that could help us to interact with that generated data. Once there drag and drop, there will be slider soon. Or widgets that would allow users to manually sort rows in a data set. Now if we want to have such functionality we are force to take resorts to other frameworks out there. Even().those().with().nasty().syntaxes() .


                  Server side functionality did not SpryData from being born, so why count for drag and drop.


                  Ha! "we are also working on cool widget tools that work with all frameworks." does that happen to be OpenAJAX support ?


                  One small tip. I see Adobe's surveymonkey surveys pop up all over the web, why not create one for Spry? Where users can just give answer on questions on what they would like to see. It might help you guys making some decisions.

                  • 6. Re: Donald Booth question!
                    @lexaka Community Member

                    Donald, open at least a piece of the mysterious curtain. Show at least a small piece of what is new ...
                    You can not imagine how long we are waiting for this.

                    • 7. Re: Donald Booth question!
                      Massimo Foti Community Member

                      Donald, open at least a piece of the mysterious curtain. Show at least a

                      small piece of what is new ...

                      You can not imagine how long we are waiting for this.


                      There is a key line in Donald's post:


                      Company policy prevents me from discussing specifics and


                      • 8. Re: Donald Booth question!
                        Dooza (Steve) Community Member

                        +1 for SpryBox, it would really make my day having that. Imagine sliding panels with it, you could make a lovely slideshow, now that would be a widget worth having.


                        Nice to hear some news, even if its nothing definate, at least its not been shelved.



                        • 9. Re: Donald Booth question!
                          dhoviss Community Member

                          I vote for a sprybox as well, something like this





                          With support for other media.


                          The point of spry box is not to reinvent the wheel, in this case, but to provide seemless functionality in SPRY for all of our needs without forcing developers to load additional frameworks.


                          SO, that means making spry more extensable.

                          What made dreamweaver so great initially was the large third party support for plugins, but I do not see many spry plugins because in part there is not a real visual commitment from Adobe to support this framework in the future.


                          -Daniel Hoviss

                          • 10. Re: Donald Booth question!
                            KenInMaine Community Member

                            It is very good to see that development on the Spry Framework is continuing.  My biggest wishlist item for the updated Spry Framework is a more robust Autosuggest Widget.  For the past 13+ years one of the biggest annoyances for me with HTML was the way the SELECT form object was implemented. It is about as user unfriendly as can be especially with long select lists.  The Spry Autosuggest Widget goes a long way towards making a more usable dropdown form field, but it still has two glaring shortcomings:


                            1. There is no easy way to pass a hidden ID value for the selected list item.
                            2. There is no easy way to limit the value the user enters into the form field to the options on the dropdown list.


                            The sad thing is that if the SELECT form field had been implemented properly to begin with one could type a string value into the SELECT form field in a manner similar to the way Microsoft Access drop down form fields work there would be much less need for the Spry Autosuggest Widget outside of really fancy select lists.

                            • 11. Re: Donald Booth question!
                              weatherangel Community Member

                              I have been anxiously watching for more updates.  I have done some major extensions to the Spry Widgets and would love to have more available to me.


                              +1 for SpryBox, it would really make my day having that.  For us, rather than integrate another framework we went with creating one and using some of the spry util functions to help out.  There is real potential in this framework that has yet to be realized.  It is light, compact, and very easy to use.  I give my developers the markup they need to use, and I can do anything I want behind the scenes.


                              If  you go with a base class type of change, please do it similarly to YUI by creating a "bundler" that allows you to bundle the needed js files into a single file, as well as gives you the minified source.  We have done our own, but it would definitely be a nice to have for anyone starting out.


                              The one thing I did notice.  Some of the widgets use the Spry.Widget.Utils name space, so if you have more than one it could cause an issue.  In my environment, we stripped out the extra, but that means that my widget revisions are possibly out of sync -- I still see the Spry.Widget.Tooltip Safari placement issue, but the latest version out says that it's been fixed?


                              Last but certainly not least, for those of us who have extended and possibly fixed things in our instances, when the next version comes out, I hope there is a detailed change release document included that we can look at.


                              Thank you VERY much for all your hard work.  This framework has taught me A LOT about clean javascript programming and how easily javascript objects can be extended.  I would not have been able to do that with any other framework (just based on their code!!).

                              • 12. Re: Donald Booth question!
                                Arnout Kazemier Community Member

                                If  you go with a base class type of change, please do it similarly to YUI by creating a "bundler" that allows you to bundle the needed js files into a single file, as well as gives you the minified source.  We have done our own, but it would definitely be a nice to have for anyone starting out.

                                That is one of the reasons I have build http://config.spry-it.com/ . It has been my lil pet application for a while now. It acts a complete stand alone CDN with advanced caching options. And it can be used as a file configure / concatenation / minification application. It basically does everything you described above but its just missing a "wizard". It supports Spry 1.0 till 1.7 (Thanks to Kin). Its Open Source, but not yet released on github / google.code







                                • 13. Re: Donald Booth question!

                                  Here's my vote  for:


                                  1. LightBox/SpryBox

                                  2. Drag-n-Drop

                                  3. Editable grid/robust CRUD support


                                  I don't want to use different libraries for all these! I just want to use Spry, and Spry alone. :-)


                                  Kin, Donald, help!