Hi Sam -- I will preface this by saying:
1. I understand your frustration that there isn't a smooth, clean migration path to the latest Tapestry. 2. I have worked with a variety of frameworks (open source, free, and otherwise) 3. I have been coding for a long, long time - doesn't make me right - just makes it possible for me to recognize when I am doing a stupid mistake, as I have so many past mistakes to chose from :-) 4. I am not going to change your mind and you are not likely to change mine. 5. You have spent a long time writing this email and I respect that. 6. Your experience is different than mine. 7. My projects: bunch of no-name start-ups (including my own), IBM, LinkedIn, Ariba ( I am not trying to impress, or more likely not, you just asked about my projects) So my response to the general points End-users will not understand the default message. --------------------------------------------------------------------------- Any message being displayed to the end-users should always be specificed and controlled by the final application developers. No two ways about. Each app is different, both in end-user technicalness and tolerance, no framework can possibly automatically generate the best or even as good an error message as end-users should expect (what I did wrong, how to solve it, link to a more detailed explaination, etc.). This needs to be done anywhy to internationalize/localize an app anyhow. I suppose if an app isn't going to be used by anyone except U.S. english speakers then this can be skipped but forget about selling to any company with a significant overseas work force. Btw. remember that British english is *different* than u.s. english (different definitions for "billion" , color vs. colour, truck vs. lorry, etc.) Default error messages tailored to developers allow for developers to have more time make the app really sing for the end-users. But I don't mean a cryptic "?SYN ERR ON 32" (bonus points if you can figure out where that error message comes from). I mean a message that says exactly what happened, information about how the framework arrived in this unhappy state, etc. The framework's end-users are developers and it should respect their time just as much as my, or your app should respect our end-users time. No migration path/hard to do migration -------------------------------------------- Well, I feel your pain. I really do. All I can say is that this is going to be true pretty much no matter what library/framework you use. Commercial or otherwise. Sure, you can say that microsoft, or some other commercial provider does a better job. But then again you are *paying* them support fees aren't you. If the same amount of money that was paid in support costs to microsoft, sun, etc. was spent to some outside consultancy house I am sure that they would be happy to sweep through an app and do the upgrade. [ In general, I get better support with open-source code I have ever gotten through most commercial providers - but I always risk being told I am an idiot, or being ignored -- worst offenders: Hibernate. ... one of the reasons I am not using Seam nor JBoss. ] Explaining to management the benefits of open source -------------------------------------------------------------------------------------- Open Source doesn't mean free. (again) Open Source doesn't mean free. Open source costs in terms of learning curve, risk that the code customized to work with/within an open source library will need to be rewritten, etc. The only thing open source means at the end of the day is that *you* have the source code. It doesn't mean an army of willing free developers. Quick question: what happens if HLS gets hit by a truck tomorrow? How about if he goes to the Tibet to discover his navel for a few years? Jesse's plane spirals into the desert? Long-term projects staying techincally up-to-date (and) costs (again) -------------------------------- Want to know what LinkedIn is using? JSP 0.92 Ariba? their own version of WebObjects. Ariba is also using "make" not "ant" to do their builds. Want to stay current on any library? It costs. Don't lie to yourself or management that they need to plan for upgrade costs at the beginning. The only (partial) answer is: 1. Lots of automated tests. 2. Isolating "your" code from "theirs" Anyhow, good luck and enjoy your weekend! -Pat On 12/1/06, Sam Gendler <[EMAIL PROTECTED]> wrote:
> +1 for new extended default messages! It is worth wading through a sea of > PMs to save development stress. This is why I like HLS and Tapestry. ... No > (mostly no) cryptic error messages! You are replacing developer stress with end-user stress. Upir average end user will not have a clue how to parse a standard Java format mask and presenting one to them will only confuse them. It helps a developer, sure, but applications are for end-users, not developers. You always have the option to include a more detailed message if you care. In the context of going from one 4.x release to another 4.x release, I don't think it is appropriate to include _unnecessary_ features that make the codebase lose backwards compatibility. Admittedly, Tap 4.1 really should be labelled tap 5, given the volume of changes to the api, but so long as it is labelled 4.1, I think an effort should be made to keep changes limited to things that don't destabilize the api unless absolutely necessary. In this case, we are talking about adding end-user visible features that are really only usable, in their default form, by developers. At least the old message could be used in an end-user visbile location. Now, every single validator will require a custom message override, either to restore the functionality of 4.0.x or to provide a message that isn't going to confuse the hell out of a non-technical end user. Sure, the new message is better for a developer when debugging, but since when does convenience stop with the developer rather than the end-user? At least give developers an override that will restore the original messages (Isn't hivemind supposed to make this easy?). Sure it is more work for the framework developers, but that's the point of a framework - to centralize the development effort in the framework itself, making it easier for users of the framework to utilize the provided functionality and cutting down on the total number of developer hours required to develop code. API changes like this are creating unnecessary work for the framework users, which kind of defeats the purpose of using a framework. The effort required to port an application of any complexity from 4.0.x to 4.1 is already very large. I think an effort should be made to keep such changes to a minimum or provide a backwards compatibility layer, preferably one that can be applied on a per-page basis so that migration can be gradual, if at all possible. I don't know about your projects, but this isn't just a matter of getting permission from a PM to change the message. No PM with even the slightest regard for an end user would let a message with a format string specified as a standard java format mask be visible to a non-developer user. If they wanted a message that included the correct format, they would specify it in a form that makes sense to a non-technical user - almost certainly using an example value rather than a format mask - Imagine a european user seeing $#,##0.00 in their error message. Commas and periods would be inverted, the currency symbol is not correct, and what the hell are those '#' symbols doing in there anyway? A change along these lines that would be actually useful and an improvement for the application user, would be the ability to specify an example value and have the validation mask applied to it automatically before it is inserted in the default error message. That way, I could show a european formatted example to european users, and a US formatted one for US users, all while still using the default error message. Now THAT would be useful, and would probably make it past the PM team without requiring a change. THe format mask by itself is useless to anyone but the developer, and you are only getting that by inconveniencing the majority of your current users. A message that is lacking in some information is often preferable to one that contains useless or confusing information, which is how the format mask would be perceived by most end users. It is worth remembering that, while the end user for Tapestry can often be considered the developers who use it, you also have to factor in the audience of users who will use apps developed on Tapestry by those developers. This is a classic example of windows error message syndrome. "An error of type 0x34FD56ABC has occured while processing your input," while useful to a developer, is actually much more frustrating to an end user than "An error has occured while processing your input." Obviously, the ideal is to tell them EXACTLY what went wrong and how to fix it, but failing that, a good design should probably prefer the latter message to the former. For me, it is becoming increasingly difficult to justify our use of Tapestry, except that we are stuck with it short of redeveloping everything we've already done. More often than not, when I give a design to an engineer, I have to explicitly mention that the current design will be obsolete in the very next version of Tapestry and leave room in the design for a revamp in the near future (and possibly another one a year later when Tap 5 hits the ether). My bosses want to know what the benefit of a framework like tapestry is if any workload saved is replaced by constant migration issues. I don't have a good answer for them, currently. On any kind of long-lived service project, there is no option to pick a version of the framework and stick with it, since doing so will leave the product in the stone age as technology advances or else will result in an internal fork of the framework source, thereby giving up the advantage of using a 3rd party product to begin with, not to mention killing any chance of ever upgrading. Building a website which will have static content once the development is complete doesn't suffer from this problem, since you just stick with the framework you have. But when building a service which will have ongoing development for years into the future, not being able to pick up point releases without major code incompatibilities becomes a real problem. The commerical alternatives offer that kind of backward compatibilty. Open source frameworks will have to as well if they want to be seriously considered for widespread adoption. And, to my mind, an application development framework has to pay attention to fundamentals of user interface design as much as the application developers do, if not more so, if the framework is truly going to cut down on workload. And at the very least, changes that will result in visible differences in a page should be explicitly listed in porting notes somewhere. Many of us won't immediately notice that an error message changed, so we won't take into account the task of modifying an entire application's set of validation messages when scheduling a migration. Missing an issue like that can be devastating to a schedule. I realize (now) that 4.1 isn't yet a full release, although the tapestry website sure seems to imply otherwise. But I sure didn't know that the first time I attempted to see what would be involved in migrating to 4.1, and there is nothing in the documentation to imply otherwise. I doubt any new user coming to tapestry today would discover it until they were well into development, unless they happened to stumble into one of the undocumented, but well known, bugs and posted a query to the list, at which point they'd be told to get the latest developer snapshot. That's exactly what happened to me, although I got lucky and found a big ol' bug on my very first day, so I didn't get too far down the migration path before I stopped and turned around. If tap 4.1 is going to be presented to the world as being ready for development, then the porting guide should be up-to-date, including mentioning the known bugs that require an upgrade to the latest dev snapshot. That would at least give framework users a fighting chance. --sam On 12/1/06, Patrick Moore <[EMAIL PROTECTED]> wrote: > Hi Sam -- > > I, for one, vote that Jesse's extended message is better... The more > meaningful detail that can be provided the better. This is especially true > because it is the default message. The first 'user' to see this message is > the developer. This developer may be in the middle of pulling their hair out > over some other issue and the last thing they need from their framework is > "Your input is wrong but guess what I am not going to give you a clue on > what is the right format (and you can't make me!)". > > Please, Please, don't be cryptic! > > +1 for new extended default messages! It is worth wading through a sea of > PMs to save development stress. This is why I like HLS and Tapestry. ... No > (mostly no) cryptic error messages! > > -Pat > > On 12/1/06, Sam Gendler <[EMAIL PROTECTED]> wrote: > > > > Given that the messages CAN be overridden, I'd like to register a vote > > for keeping very simple messages as the default (since I tend to use > > them as is) and letting individual users override them as necessary. > > Also, keeping the messages unchanged would aid those of us who will > > have to port applications to 4.1 at some point. It seems like a > > change which isn't _necessary_ and since I use the default message in > > many cases, I'd actually have to go and override the default message > > throughout my app when I port it (either that, or get PM to buy into > > the new text, which would take about 10 times as long). Given that > > 4.1 isn't _supposed_ to have major upgrade incompatibilities (at > > least, I'd assume so given the similarity in version number), it'd be > > nice to keep the messages the same unless absolutely necessary. > > > > --sam
