I'm delighted with the web centric approach to the next gen architecture. (Although a bit skeptical about Silverlight). In the "what's in it for me" vein I'd like to pose the following question:
Is it possible to develop the UI in such a fashion that modules, parts of the UI, could be used in our public websites? The most obvious example would be the patron's address/contact information.
I think all of us struggle with our development efforts and I am also concerned with Silverlight. While I understand the push to use something that is simple and straight forward (Microsoft Centric Approach), is it the best for longevity and compatibility. While MS currently supports Silverlight on various browsers that could change.
Using HTML 5.0, CSS, or a Javascript / Ajax option opens the entire community into an App store kind of approach. If Center Theatre Group develops this really cool widget and module, we could easily share it with the entire Tessitura community, and because it is using standards, more browsers and applications should be available.
Thoughts?
Dave
Perhaps we should start a Siverlight discussion. I'm glad I'm not the only skeptic.
Microsoft has a HORRIBLE track record regarding web compatibility. There are people very high in Microsoft who want to use the browser as a sales tools for their OS. Silverlight looks to be another example of this.
That being said, I do acknowledge the need for some kind of thin client development environment. The next gen cannot be done all in javascript. And there's not really much in the way of choice, Flash is not right, it may be that Silverlight is the only workable solution.
Dave: My thoughts exectly.
Mark: You said: "The next gen cannot be done all in javascript." I don't see why not. We're just talking about a client interface here. What is there, in the way of displaying/submitting/interacting with data, that couldn't be done with HTML and JavaScript?
-Morgan
Hi Morgan, I'm doubtful about doing a robust DB client in all AJAX mainly because of the need for strong type and syntax enforcement at the UI layer.
It can be done, but it requires a lot of custom development, rather than dropping a control on a form.
You can all see that this will not be an easy choice. There is no perfect solution, and we are also attempting to anticipate not only technology but business needs many years into the future. This is why the Development Team and Board Steering Committee have spent a lot of time and resources examining the merits of various choices. The examination is being done from many perspectives: stability and compatability, ability to provide the functionality required to meet our current and future business requirements, longevity and vendor/community support and adoption, fit with the agile, test-driven development model, migration and conversion, training of development and support staff, training of Member administrators and end-users, and other considerations.
The choice of Silverlight is by no means final, nor is it necessarily exclusive of also using other options side-by-side. We have people with a great deal of expertise doing the technology spikes to help us arrive at the best possible choice, and that is a big part of the work being done now in the early stages of Release 1. This input is excellent and appreciated, and I will also be interested to see the recommendations that come from the team as they do this work.
Alan
Alan,
I hope you didn’t see my comments and I suspect anyone else’s as something was bad or wrong. I think we are all talking generalities and we are all out there guessing a bit. I, like Mark, agree that it is exciting that Tessitura is taking this on in such a way to really discover what is best for the community. I think Silverlight isn’t a bad choice, just something to be mindful of.
I would love for you to put forth to the committee the idea of the Tessitura App Store (for lack of a better name). It would be great that all of us can share and use each other code where it makes sense. It also builds upon the idea that Chuck talked about yesterday of having a high degree of customization. If we have this concept in mind while developing I think we could see a huge advantage over time.
Just my two cents.
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Alan Levine Sent: Thursday, January 14, 2010 11:46 AM To: Dave Alton Subject: Re: [Tessitura Next Generation Forum] Modularity in the UI - Web Widgets?
From: Morgan L'Argent <bounce-morganlargent2717@tessituranetwork.com> Sent: 1/14/2010 1:27:32 PM
You were sent this message automatically by www.tessituranetwork.com because you subscribed to the Tessitura Next Generation forum email notifications. You may reply to this message or visit the site to reply to the post above. If replying via email, please consider deleting the previous message text before sending to help with readability on the site. Thank you!
the Tessitura App Store - TAPPS
Perfect name Dave, it encapsulates the whole concept.
Dave,
on the contrary, the comments truly are helpful and welcome, and keep them coming. I just wanted to point out how challenging a decision this will ultimately be, and that the team is giving it a great deal of careful consideration.
I think I can safely say that you can count on the creation of some sort of mechanism for sharing custom widgets and other member-created components, just as Tessitura Network already provides a forum for sharing user-developed reports and utilities.
I'm just curious if there have been any decisions on the Silverlight vs. other options front. Alan? :)
No decisions yet. We're actually working on a dual track approach in development right now, finishing 3 or 4 stories that have UI components in both extJS (a Javascript library) and Silverlight. So far both have their ups and downs. Silverlight make solving cross domain issues, much easier and has lots of visual and customization potential. extJS makes TDD (Test Driven Development) easier, is more open but requires a bit more work on the security and is a slightly higher hurdle on the customization side. Like most choices, there probably is not going to be an obvious answer but we're committed to learning as much as we can. Then making a decision by the end of Iteration 4, in 3 more weeks. And finally, of course, EMBRACING the decision.
Further thoughts here are always welcome!
I suppose it's a bit early to be looking to HTML 5 to solve some of your issues. Would be nice if that was further along in adoption.
I think this approach is the best. Keeping options open until the last possible minute then letting us weigh in on it. I agree we are going to see advantages and disadvantages to each UI method. I would ask a few pointed questions.
1. Will whatever we choose give us the most flexibility in the future? The choice that we make here is critical, the last version of Tessitura ran for 10 years on its platform, will Silverlight allow us to run for that length of time or will Java? I think the answer to both of those is likely a conditional yes. I think the more important question is will either of those allow continued backward support over the years that they are utilized, or will they make it easy enough to change to a more current UI, without impacting the end users? There are obvious cost considerations in these choices.
2. Which one will allow for the most customization? The thing to keep in mind about customization is that it adds complexity. If you want something that is fully customizable by a large portion of the installed base, how do you keep the code from breaking due to customizations? If you choose to limit customization will we continue to be able to get the job done with the software?
3. Security will continue to be a very hot topic. If you look at the threat vectors that existed 2 years ago to today you will see the sophistication has increased exponentially. They continue to build tools that are easier and easier to attack web sites and place errant code to infect people that use the website from a legitimate source. I favor a very flexible / dynamic approach to security with many layers. Having an application be secure in this way adds another layer and I would put a heavy emphasis on it.
Just my two cents worth. When we do get to the point where we make that decision it will have to be a decision we embrace just as you say Chuck, it won’t make any sense to second guess or continue to bring up the obvious disadvantage that the solution provides. Test now and choose well!
Dave Alton
CIO
Center Theatre Group
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Chuck Reif Sent: Friday, February 05, 2010 9:16 AM To: Dave Alton Subject: Re: [Tessitura Next Generation Forum] RE: Modularity in the UI - Web Widgets?
From: Andrea Crain <bounce-andreacrain8512@tessituranetwork.com> Sent: 2/5/2010 10:59:58 AM
I'm glad to hear that you're taking a thoughtful approach to both options, since the best way to find what's best for a project is to actually test it.
I would like to add my own concern with the use of Silverlight for the NextGen UI. Though it has a number of positives, my own experience with Silverlight has been that it's a less efficient (with client resources) and stable platform overall than Javascript.
The cross domain issue with Javascript is understandable, though, and I know that it can be a bit more work overcoming that. Ultimately, though, I think that Javascript is a more natural fit for web interfaces. The model of website navigation is pretty decent, and platforms like Silverlight and Flash have a bad habit of overriding expected behavior, while well developed Javascript tends to enhance it.
I also think Javascript will give future Tessitura development more room to move; as HTML5 and future technologies mature, I think it will be harder to shift to them if the site is attached to a more restricted, proprietary platform.
Personally, I hope that the development team decides that its benefits outweigh Silverlight's, but I understand what I tough decision it will be.
Either way, best of luck.
Eric Sipple
The folks developing Ext JS are already looking towards HTML 5. http://www.extjs.com/blog/2010/01/14/html5-video-canvas-extjs/
JavaScript and HTML (any version) go hand in hand. But with Silverlight, it's a closed system. It only uses the browser as a wrapper for delivering an embedded web app. So, going that route, HTML 5 or any other standards are moot.
I haven't used Ext JS, but reading through the docs, it looks like a pretty nice library. They say it's interoperable with jQuery - thumbs up from me.
There's an additional aspect of Silverlight (especially Silverlight 4) that has its advantages and that's when it comes to interacting with the OS. We are trying to make a browser based client here but there are some requirements of the current system that pose a challenge. One of these is ticket printing. Right now we're able to use OS (Windows) functions to print directly to a specific printer. This is not possible through a browser, where printing has to be controlled by the browser's printing functionality. Yes, there are ways to bypass the browser print control but not (as far as I know) to change the destination of the print stream without using the browser print control. Another aspect is MS Office integration, similar to the things we do now with controlling Word merges directly from the application. There may be other ways to deal with these problems (and I'd welcome suggestions) but they are problems we know we'll have to face.
Also at this point we think that we'll have to use something other than Javascript when we get to seatmap rendering in order to make an acceptable presentation. Now this is far in the future and there may be other ways to deal with this as well. I just wanted to point out that even if some form of Javascript turns out to the best way to go, there may have to be exceptions in certain areas of the application.
And I'm loving the discussion by the way, and hope that if you got opinions or thoughts that you will share them!
Hi, Chuck,
Oh... I wasn't thinking of the JavaScript path as using an off-the-shelf browser. My thought was that it would use a browser engine (like WebKit, for example) to render the interface within a custom client application. That way it would be easy to modify the interface using tools lots of people already know, but still have a way to handle functions that need to interact with the OS. Another way that might work would be to use an off-the-shelf browser but write some Tessitua plugins to handle printing, exporting, etc.