Comments on: The Cost of Developing Rich Interfaces http://www.clientcide.com/deep-thoughts/the-cost-of-developing-rich-interfaces/ Making stuff work on the other side of the request. Mon, 30 Aug 2010 15:20:34 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Aaron N. http://www.clientcide.com/deep-thoughts/the-cost-of-developing-rich-interfaces/comment-page-1/#comment-32172 Aaron N. Fri, 03 Apr 2009 20:36:07 +0000 http://www.clientcide.com/?p=851#comment-32172 Good stuff Ben. In my mind, all those barriers you describe only highlight the importance of developing abstract patterns for greater code reuse. If you know your SlideShow class works in all browsers, it's one less thing you have to test. The other thing is that it illustrates the importance of "selling" your work <i>after</i> the fact. I.e. once the product is launched, give a talk to your coworkers and explain the product enhancements you added with clientside technology, what that entailed, the technical challenges it represented, etc. Good stuff Ben. In my mind, all those barriers you describe only highlight the importance of developing abstract patterns for greater code reuse. If you know your SlideShow class works in all browsers, it’s one less thing you have to test. The other thing is that it illustrates the importance of “selling” your work after the fact. I.e. once the product is launched, give a talk to your coworkers and explain the product enhancements you added with clientside technology, what that entailed, the technical challenges it represented, etc.

]]> By: Ben Tyger http://www.clientcide.com/deep-thoughts/the-cost-of-developing-rich-interfaces/comment-page-1/#comment-32171 Ben Tyger Fri, 03 Apr 2009 19:26:20 +0000 http://www.clientcide.com/?p=851#comment-32171 I have come to love Mootools. Most of my issues are not with Mootoo, but management's view of JavaScript. With the new JavaScript frameworks, it does clean up many of the common issue and give us web developer more functionality to create new things. I have found that most managers, like many developers did in the past, don't see the amount of effort it takes to make a rich HTML/CSS/JavaScript UI. This makes it hard to develop rich environments with unreasonable deadlines/budgets. Managers still see JavaScript as a limited/simplistic/easy language. Also it hard for them to understand that you have lots of rendering engines you have to worry about. To make matter worse, the most common browser is also the flakiest. So QA time/costs are high too. I have come to love Mootools. Most of my issues are not with Mootoo, but management’s view of JavaScript. With the new JavaScript frameworks, it does clean up many of the common issue and give us web developer more functionality to create new things. I have found that most managers, like many developers did in the past, don’t see the amount of effort it takes to make a rich HTML/CSS/JavaScript UI. This makes it hard to develop rich environments with unreasonable deadlines/budgets. Managers still see JavaScript as a limited/simplistic/easy language. Also it hard for them to understand that you have lots of rendering engines you have to worry about. To make matter worse, the most common browser is also the flakiest. So QA time/costs are high too.

]]> By: Aaron N. http://www.clientcide.com/deep-thoughts/the-cost-of-developing-rich-interfaces/comment-page-1/#comment-32115 Aaron N. Fri, 20 Mar 2009 16:05:08 +0000 http://www.clientcide.com/?p=851#comment-32115 The reason for scripts.json is so that other things than browsers can read the dependency list and do things with it (like build tools, docs engines, etc). If you declared it in the JS file itself, then the only thing that could read it would be a javascript parser or one you wrote yourself. By having the map in a json file, anything that can read json (i.e. nearly everything) can take that file and do things with it. It's a JavaScript problem, and MooTools solution. The reason for scripts.json is so that other things than browsers can read the dependency list and do things with it (like build tools, docs engines, etc). If you declared it in the JS file itself, then the only thing that could read it would be a javascript parser or one you wrote yourself. By having the map in a json file, anything that can read json (i.e. nearly everything) can take that file and do things with it. It’s a JavaScript problem, and MooTools solution.

]]> By: Thomas Allmer http://www.clientcide.com/deep-thoughts/the-cost-of-developing-rich-interfaces/comment-page-1/#comment-32113 Thomas Allmer Fri, 20 Mar 2009 09:11:28 +0000 http://www.clientcide.com/?p=851#comment-32113 @aaron, yeah sorry maybe it's just my lazy code style. That's the reason I said it's important <b>for me</b>. And I (again just me and my crazy style... :p) believe that there could be a better solution than the scripts.json... If you write your dependence information in an separate file that has nothing to do with the actual plugin I guess it's like putting the price tag of a car not on the car but on a list that's hanging in the headquarter lobby of your company. Now you stand in front of the car and you what to know it's price - you would have to got to the headquarter lobby and check it there. And what if your not at the headquarter but in some remote outpost? I guess It would be easier to just add the price tag to the car... I mean what's happen if you are not allowed to update the list - your just allowed to bring a car... Man that was a strange comparison - don't wanna offend anyone but that's how I'm experiencing it. Jet again it doesn't really matter as I'm working on a solution to <b>my problems </b> you don't need to listen I'm just blabbering... :p @aaron, yeah sorry maybe it’s just my lazy code style. That’s the reason I said it’s important for me. And I (again just me and my crazy style… :p) believe that there could be a better solution than the scripts.json…
If you write your dependence information in an separate file that has nothing to do with the actual plugin I guess it’s like putting the price tag of a car not on the car but on a list that’s hanging in the headquarter lobby of your company. Now you stand in front of the car and you what to know it’s price – you would have to got to the headquarter lobby and check it there. And what if your not at the headquarter but in some remote outpost? I guess It would be easier to just add the price tag to the car… I mean what’s happen if you are not allowed to update the list – your just allowed to bring a car…
Man that was a strange comparison – don’t wanna offend anyone but that’s how I’m experiencing it. Jet again it doesn’t really matter as I’m working on a solution to my problems you don’t need to listen I’m just blabbering… :p

]]> By: Aaron N. http://www.clientcide.com/deep-thoughts/the-cost-of-developing-rich-interfaces/comment-page-1/#comment-32108 Aaron N. Thu, 19 Mar 2009 17:08:31 +0000 http://www.clientcide.com/?p=851#comment-32108 @Thomas, I would argue that the things you complain of are all manageable if you design your code differently. Certainly I've illustrated here at Clientcide that releasing lots of code is possible, even when that code includes image assets and whatnot. Dependency management is something we've already solved (with our scripts.json maps and build scripts that resolve dependencies). @Thomas, I would argue that the things you complain of are all manageable if you design your code differently. Certainly I’ve illustrated here at Clientcide that releasing lots of code is possible, even when that code includes image assets and whatnot. Dependency management is something we’ve already solved (with our scripts.json maps and build scripts that resolve dependencies).

]]> By: Thomas Allmer http://www.clientcide.com/deep-thoughts/the-cost-of-developing-rich-interfaces/comment-page-1/#comment-32107 Thomas Allmer Thu, 19 Mar 2009 11:36:29 +0000 http://www.clientcide.com/?p=851#comment-32107 I'm a really lazy guy and I hate it to reinvent the wheel, however I believe MooTools currently isn't as far as to be reused easily by anyone. It's still too complicated finding out what plugin needs what files (js, css, images...) And if you have a Layout for a Plugin how can you easily change it (if css only changes are not enough) without recreating the functionality. I think that's pretty important "for me" as I don't want to think during development about all those things... And I guess most of the people out there just include the full core and more code during development because it's the only way you can develop without suddenly getting a not defined error... :p don't get me wrong - I love MooTools and I'm trying to adopt it to my needs... I'm currently heaving my basic UI class you can see at: http://www.delusionworld.com/mootools/general-mootools-ui/ I'm also trying to create a manager for locally installed plugins but there is still some work to do before it's usable by "others". I’m a really lazy guy and I hate it to reinvent the wheel, however I believe MooTools currently isn’t as far as to be reused easily by anyone.
It’s still too complicated finding out what plugin needs what files (js, css, images…)
And if you have a Layout for a Plugin how can you easily change it (if css only changes are not enough) without recreating the functionality.
I think that’s pretty important “for me” as I don’t want to think during development about all those things…

And I guess most of the people out there just include the full core and more code during development because it’s the only way you can develop without suddenly getting a not defined error… :p

don’t get me wrong – I love MooTools and I’m trying to adopt it to my needs… I’m currently heaving my basic UI class you can see at: http://www.delusionworld.com/mootools/general-mootools-ui/

I’m also trying to create a manager for locally installed plugins but there is still some work to do before it’s usable by “others”.

]]> By: Aaron N. http://www.clientcide.com/deep-thoughts/the-cost-of-developing-rich-interfaces/comment-page-1/#comment-32106 Aaron N. Wed, 18 Mar 2009 15:21:46 +0000 http://www.clientcide.com/?p=851#comment-32106 You'll need to reach out to Digitarald. Here's the codebase (http://www.redracer.org/). You’ll need to reach out to Digitarald. Here’s the codebase (http://www.redracer.org/).

]]> By: Johan http://www.clientcide.com/deep-thoughts/the-cost-of-developing-rich-interfaces/comment-page-1/#comment-32104 Johan Wed, 18 Mar 2009 08:23:40 +0000 http://www.clientcide.com/?p=851#comment-32104 @Aaron, indeed there are enough ways to release code, I am starting to do this myself. However, a central repository or listing would make a big difference: an overview with full coverage of everything available, version managed, standardized documentation & examples and registered dependencies are things that make the difference between amateur and professional. You mention you are slowly working on this, I am willing to help. @Aaron, indeed there are enough ways to release code, I am starting to do this myself. However, a central repository or listing would make a big difference: an overview with full coverage of everything available, version managed, standardized documentation & examples and registered dependencies are things that make the difference between amateur and professional. You mention you are slowly working on this, I am willing to help.

]]> By: Aaron N. http://www.clientcide.com/deep-thoughts/the-cost-of-developing-rich-interfaces/comment-page-1/#comment-32103 Aaron N. Wed, 18 Mar 2009 03:46:09 +0000 http://www.clientcide.com/?p=851#comment-32103 @Dan, you'd be surprised. When you release code, yes, people find your bugs, but that's a good thing. And sometimes they even help you fix them. @Dan, you’d be surprised. When you release code, yes, people find your bugs, but that’s a good thing. And sometimes they even help you fix them.

]]> By: Dan http://www.clientcide.com/deep-thoughts/the-cost-of-developing-rich-interfaces/comment-page-1/#comment-32102 Dan Wed, 18 Mar 2009 03:10:31 +0000 http://www.clientcide.com/?p=851#comment-32102 Thanks for the kick up the butt! I've got a growing collection of classes to solve different problems that have arisen in our day to day studio work and really should start posting them. The only thing I'm concerned about is releasing classes that aren't bulletproof and causing people problems when they try to dump them in and go. In my eyes I guess they'll never be done though! Thanks for the kick up the butt! I’ve got a growing collection of classes to solve different problems that have arisen in our day to day studio work and really should start posting them. The only thing I’m concerned about is releasing classes that aren’t bulletproof and causing people problems when they try to dump them in and go. In my eyes I guess they’ll never be done though!

]]>