The more complex my forms get the more I see control events fired that I'd like to eliminate. With a completely ajaxified site, additional rules come into play about what gets processed on the server even if we're only doing partial postbacks. To minimize the burden on the server, some activity should be moved to the client.
None of this is unique to RadControls, but effective use of RadControls is only possible when someone has a solid handle on all of the base concepts. I know that my understanding of the ASP.NET page life cycle is limited and only time and more reading will help to internalize the entire process. But I know I'm not alone, and many issues that people face here are directly related to ineffective management of the entire page cycle.
I know a lot of questions can be answered by taking a week-long class on advanced ASP.NET with a quality provider. But "for the masses" I'm wondering if anyone is aware of free resources, hopefully provided by Telerik, that walk through the full execution of components from client to server so that we can get a good handle on exactly what is happening under the covers. Here are examples of the sort of information that I think would be helpful to everyone. I don't want the answers to specific questions, these are just examples of the scope/categories of questions that people may have:
- Some code is best put in server-side Page_Init rather than Page_Load. What are the rules for determining this?
- Some code is best in PreRender or other events. Why?
- What should we specifically eliminate from Page_Load or other life cycle events to minimize transaction time and redundant activity?
- When we see Init, Load, and other events firing for ajaxified controls that are unrelated to an event that we're processing, is that a bad thing?
- What's the best way to prevent a data source from re-binding a control that doesn't seem to need a data refresh. In other words, the user selects an item from a databound list and then clicks a button - how do we stop the list from getting repopulated on unrelated partial postbacks?
- What are some good examples of events where a call to the server on partial postback can be replaced with a client-side event?
- When and how do we replace a partial postback with a client-side web service call?
If I could get a dream realized I would find the following resources:
- A chat room with people actively discussing these topics. Heck, it's easy to create any number of IRC channels.
- A forum section under this Ajax forum dedicated to event handling.
- Blogs discussing topics like these in-depth.
- Telerik TV full of "Watch Minute" sessions on specific events and aspects of client vs server handling.
- Telerik Help pages, articles, etc on using controls in the context of the page cycle, in addition to the more mundane details of class members and control placement.
- Lots of tiny examples of specific types of event handling. Unfortunately the Telerik examples include lots of "stuff" that complicate their examples, like external scripts and CSS, header and footer controls, and other code modules that are required to support the plumbing of the core examples. Of course these help us to understand more complex usage of the software, but it would be really nice to also have smaller, more "atomic" examples with fewer dependencies, with controls used in different ways in the page life cycle.
What do you think?
8 Answers, 1 is accepted
0
Todd Anglin
Top achievements
Rank 2
Rank 2
answered on 06 May 2009, 05:16 AM
Great suggestions, Tony! We'll log your requests in our Content system and get them scheduled for production. We'll try to at a minimum create videos and blog posts that address these areas of interest.
In the mean time, if you have any specific pain points or questions, feel free to ask!
-Todd
0
TonyG
Top achievements
Rank 1
Rank 1
answered on 06 May 2009, 12:01 PM
Thanks for the encouragement, Todd - always good to see your notes and vids.
Maybe I should post these elsewhere, but here are two related examples just to kick this off. I'll preface by saying I do most of my work with thick forms and services, so every time I get involved in an ASP.NET project I feel rusty. Because of this you'll see bursts of cluelessness here.
I just spent two days trying to figure out why code wasn't working after I transitioned from straight .aspx to master/content with usercontrols on the content pages. As you can imagine there was some juggling with AjaxManager and proxies. There were two issues. First, one UC wasn't appearing, and second, another was "magically" disappearing after an event fired on one of the UC controls. In debug I saw my UCs instantiating and event handlers wired up, but for the first UC when the page rendered there was blank space where I expected the UCs. I asked my business partner (an MVP!) who's not familiar with RadControls to look at it and after looking closely he suggested it may be an ASP.NET bug.
It turns out the RadAjaxManager was missing an AjaxSetting to update the UC, but somewhere _after_ the Page_PreRender the UC was getting wiped out because of it. It would sure help to understand when RadControls are doing specific things outside the scope of what we can see in debug.
For the problem where the usercontrol disappeared after clicking a control, to diagnose the issue I removed all declarative AjaxSettings and was trying to figure out if components need to update themselves or if I need panels around some and not others, etc. It was a lot of hunt n peck. But I eventually found he answer here:
http://www.telerik.com/help/aspnet-ajax/ajxloadusercontrols.html
I wasn't saving the name of my UC in Viewstate, so when the event handler was fired, the server didn't know what control fired the event. Imagine how tough it is to debug a situation where the server is unaware of a control that just clearly fired an event - and because the control didn't know what the control was, poof, it disappeared when the server completed the transaction. The solution here is to reload the UC at Page_Load time, so that it's instantiated on the server and ready to process the event that the client fired. In a thick client the control is always there so I wasn't expecting this. Knowing that control events are fired after Page load events is critical to understanding that problem. My fault was not remembering that we need to completely rebuild the environment on the server in order to process the client's requests. It's all about page life cycles and the contract that client and server need to respect.
But that brings me to the "effective" event handling part. For now in this new project I have all controls in a UC completely rebuilding themselves on every partial postback. The screen isn't refreshing but there is significant lag time as all controls are rebuilt off the database whether they need to be or not. (Hey, even just a few seconds is "significant".) In addition to better use of ViewState, SessionState, and/or Caching, I'd like to get a better understanding of how I can eliminate some of this redundant and expensive postback activity for more instantaneous turnarounds.
How does this fit with Telerik? Well, it's not the company's job to educate numbnuts like me who forget or aren't aware of all of the rules, but I see a lot of postings in this forum where the solution came through an understanding of exactly what and when things were happening. Mind you, I search the depths of this forum, Google, demos, and the product docs, and finding issues can still be hard. Documenting some of these mysteries and allowing people to chat about them live should go a long way toward expediting development for a lot of us, reducing forum time (which BTW was very painful in the old forum but much better now), and increasing satisfaction and productivity with the tools.
Nuff outta me. Thanks again.
Maybe I should post these elsewhere, but here are two related examples just to kick this off. I'll preface by saying I do most of my work with thick forms and services, so every time I get involved in an ASP.NET project I feel rusty. Because of this you'll see bursts of cluelessness here.
I just spent two days trying to figure out why code wasn't working after I transitioned from straight .aspx to master/content with usercontrols on the content pages. As you can imagine there was some juggling with AjaxManager and proxies. There were two issues. First, one UC wasn't appearing, and second, another was "magically" disappearing after an event fired on one of the UC controls. In debug I saw my UCs instantiating and event handlers wired up, but for the first UC when the page rendered there was blank space where I expected the UCs. I asked my business partner (an MVP!) who's not familiar with RadControls to look at it and after looking closely he suggested it may be an ASP.NET bug.
It turns out the RadAjaxManager was missing an AjaxSetting to update the UC, but somewhere _after_ the Page_PreRender the UC was getting wiped out because of it. It would sure help to understand when RadControls are doing specific things outside the scope of what we can see in debug.
For the problem where the usercontrol disappeared after clicking a control, to diagnose the issue I removed all declarative AjaxSettings and was trying to figure out if components need to update themselves or if I need panels around some and not others, etc. It was a lot of hunt n peck. But I eventually found he answer here:
http://www.telerik.com/help/aspnet-ajax/ajxloadusercontrols.html
I wasn't saving the name of my UC in Viewstate, so when the event handler was fired, the server didn't know what control fired the event. Imagine how tough it is to debug a situation where the server is unaware of a control that just clearly fired an event - and because the control didn't know what the control was, poof, it disappeared when the server completed the transaction. The solution here is to reload the UC at Page_Load time, so that it's instantiated on the server and ready to process the event that the client fired. In a thick client the control is always there so I wasn't expecting this. Knowing that control events are fired after Page load events is critical to understanding that problem. My fault was not remembering that we need to completely rebuild the environment on the server in order to process the client's requests. It's all about page life cycles and the contract that client and server need to respect.
But that brings me to the "effective" event handling part. For now in this new project I have all controls in a UC completely rebuilding themselves on every partial postback. The screen isn't refreshing but there is significant lag time as all controls are rebuilt off the database whether they need to be or not. (Hey, even just a few seconds is "significant".) In addition to better use of ViewState, SessionState, and/or Caching, I'd like to get a better understanding of how I can eliminate some of this redundant and expensive postback activity for more instantaneous turnarounds.
How does this fit with Telerik? Well, it's not the company's job to educate numbnuts like me who forget or aren't aware of all of the rules, but I see a lot of postings in this forum where the solution came through an understanding of exactly what and when things were happening. Mind you, I search the depths of this forum, Google, demos, and the product docs, and finding issues can still be hard. Documenting some of these mysteries and allowing people to chat about them live should go a long way toward expediting development for a lot of us, reducing forum time (which BTW was very painful in the old forum but much better now), and increasing satisfaction and productivity with the tools.
Nuff outta me. Thanks again.
0
ManniAT
Top achievements
Rank 2
Rank 2
answered on 06 May 2009, 01:55 PM
Hi Tony,
you are asking some interesting questions.
I not able to give specific answers here but I have some ideas (thoughts) about those things in general.
I would divide the "performance problem" in two parts.
First part is the overall optimization.
And the second part is the specific optimization.
Especially for the first part there is a huge number of possibilities.
A thing I use in general is telerik compression. This reduces the byte size (raw content) of my pages in a range from 70% to almost 50% depending on the content. (Be sure to enable PostBackCompression).
Another thing is the use of sprites which (if well done) reduces the GET calls to the server. And with this also image caching takes place which also helps a lot.
Another thing is the viewstate - also a good place to save transfer volumes.
The next thing is caching.
What you can do here depends very much on the application.
a.) How dynamic is your data
b.) How many users are accessing your site
In a lot of cases (when it comes to high frequency) - a little time (like 1 to 10 seconds) does often not change the information - but can bring up a much better pages / second rate.
Here you should always remember that we are disconnected. So the information a user see depends on "when he hits the enter key".
In other words - if I deliver a 3 seconds old page (due to caching) it is some kind of an outdated information - but on the other side it is the same he would have got if he had hit enter 3 seconds before.
Caching (client side in this case) is also an interesting thing on webservices. Instead of retrieving a list of customers (always the same) on every call it could help a lot if we can solve this in two calls - where the first tell's if the data has to be retrieved - or if the data already transmitted (at the last call) to the client is up to date.
And Web Services lead me to the second point - situation specific optimizations.
You've been talking about "load, PreRender" and other events like this.
A lot of things can be done outside the scope of normal ajax calls (I talk about manager or panels). You simply call WebMethods on a page or "real web services". I see two main usages on this.
The first is that a lot of things don't need more (validation for an example) and the other is the fact the a lot of the telerik controls have a very rich client API.
With the use of these APIs you can save such "regular postbacks" - instead you get the data from a web service and feed the functions with the result(s) of that calls.
Another approach could be the usage of CSS or direct style manipulation.
For an example: If a longer initial loading time is acceptable you could "hide" some complex controls via a style (visibility) and show them when they are needed.
A last thought about it: I guess the most possible performance boost could be achieved by some kind of prediction.
So if you know that the user would seldom look at (as an example) "order details" you can choose a loading mechanism which loads those details on demand.
Or if you know that the user is primarily interested in the open (not payed) invoices you could (by sorting) show them on the first page while the others can bee retrieved on the following pages.
I would say APSX (ajax) optimization follows the same rules as for an example C (C++) code optimizing.
Of course you can change a for to a do-while loop and use static values instead of variables - and yes this will bring you some performance. But in most cases a better algorithm brings much more.
If you are able to serve the user with the needed data on the first call this for sure helps a lot.
The most effective event handling is avoidance :)
I hope some of my thought may help you a little.
Regards
Manfred
you are asking some interesting questions.
I not able to give specific answers here but I have some ideas (thoughts) about those things in general.
I would divide the "performance problem" in two parts.
First part is the overall optimization.
And the second part is the specific optimization.
Especially for the first part there is a huge number of possibilities.
A thing I use in general is telerik compression. This reduces the byte size (raw content) of my pages in a range from 70% to almost 50% depending on the content. (Be sure to enable PostBackCompression).
Another thing is the use of sprites which (if well done) reduces the GET calls to the server. And with this also image caching takes place which also helps a lot.
Another thing is the viewstate - also a good place to save transfer volumes.
The next thing is caching.
What you can do here depends very much on the application.
a.) How dynamic is your data
b.) How many users are accessing your site
In a lot of cases (when it comes to high frequency) - a little time (like 1 to 10 seconds) does often not change the information - but can bring up a much better pages / second rate.
Here you should always remember that we are disconnected. So the information a user see depends on "when he hits the enter key".
In other words - if I deliver a 3 seconds old page (due to caching) it is some kind of an outdated information - but on the other side it is the same he would have got if he had hit enter 3 seconds before.
Caching (client side in this case) is also an interesting thing on webservices. Instead of retrieving a list of customers (always the same) on every call it could help a lot if we can solve this in two calls - where the first tell's if the data has to be retrieved - or if the data already transmitted (at the last call) to the client is up to date.
And Web Services lead me to the second point - situation specific optimizations.
You've been talking about "load, PreRender" and other events like this.
A lot of things can be done outside the scope of normal ajax calls (I talk about manager or panels). You simply call WebMethods on a page or "real web services". I see two main usages on this.
The first is that a lot of things don't need more (validation for an example) and the other is the fact the a lot of the telerik controls have a very rich client API.
With the use of these APIs you can save such "regular postbacks" - instead you get the data from a web service and feed the functions with the result(s) of that calls.
Another approach could be the usage of CSS or direct style manipulation.
For an example: If a longer initial loading time is acceptable you could "hide" some complex controls via a style (visibility) and show them when they are needed.
A last thought about it: I guess the most possible performance boost could be achieved by some kind of prediction.
So if you know that the user would seldom look at (as an example) "order details" you can choose a loading mechanism which loads those details on demand.
Or if you know that the user is primarily interested in the open (not payed) invoices you could (by sorting) show them on the first page while the others can bee retrieved on the following pages.
I would say APSX (ajax) optimization follows the same rules as for an example C (C++) code optimizing.
Of course you can change a for to a do-while loop and use static values instead of variables - and yes this will bring you some performance. But in most cases a better algorithm brings much more.
If you are able to serve the user with the needed data on the first call this for sure helps a lot.
The most effective event handling is avoidance :)
I hope some of my thought may help you a little.
Regards
Manfred
0
TonyG
Top achievements
Rank 1
Rank 1
answered on 06 May 2009, 08:21 PM
Manfred - that's exactly the sort of info I'm talking about (and it dove-tails with much of what Todd has written: http://telerikwatch.com/search/label/Optimization%20Tips)
Examples of these techniques in use would be very helpful - hey, I don't suppose there's a wiki somewhere for Telerik developers, is there? It seems that's a missing component when we have a forum, blogs, docs, demos, vids...
Minor note about ViewState, I tend to not use it for big batches of data because I figure the wire is already getting hit with x bytes of data to populate the UI, so putting that same data in ViewState only doubles the load from the server, and adds x bytes back from client to server. So if anything, for populating grids and trees that have a lot of scrolling data, I'll use session state.
However, to avoid REpopulating those controls at all, yes, using web services or other mechanisms is definitely the next step. I figure my development is three-phased. Make it work with flicker (don't worry about Ajax). Add Ajax to show the client where we're going. Finally, make it performant. Getting through the first two phases is fairly quick but without in-depth understanding of the "effective" way to do all of this, getting performance requires a bit of re-wiring - it's valuable and required but does add some time and cost to a project.
I think that's where I'm going with all of this - not just using RadControls to make a site pretty, but really making the best use of them to make them efficient as well. At some point it's basic ASP.NET, and not Telerik's responsibility to host such discussions. But I think there are many nuances in proper use of RadControls which will keep information like this on-topic and of particular interest to RadControls users.
Examples of these techniques in use would be very helpful - hey, I don't suppose there's a wiki somewhere for Telerik developers, is there? It seems that's a missing component when we have a forum, blogs, docs, demos, vids...
Minor note about ViewState, I tend to not use it for big batches of data because I figure the wire is already getting hit with x bytes of data to populate the UI, so putting that same data in ViewState only doubles the load from the server, and adds x bytes back from client to server. So if anything, for populating grids and trees that have a lot of scrolling data, I'll use session state.
However, to avoid REpopulating those controls at all, yes, using web services or other mechanisms is definitely the next step. I figure my development is three-phased. Make it work with flicker (don't worry about Ajax). Add Ajax to show the client where we're going. Finally, make it performant. Getting through the first two phases is fairly quick but without in-depth understanding of the "effective" way to do all of this, getting performance requires a bit of re-wiring - it's valuable and required but does add some time and cost to a project.
I think that's where I'm going with all of this - not just using RadControls to make a site pretty, but really making the best use of them to make them efficient as well. At some point it's basic ASP.NET, and not Telerik's responsibility to host such discussions. But I think there are many nuances in proper use of RadControls which will keep information like this on-topic and of particular interest to RadControls users.
0
ManniAT
Top achievements
Rank 2
Rank 2
answered on 06 May 2009, 09:00 PM
Tony,
since I don't know you - maybe my tip is wrong - but if you are a bit like me it maybe helpful.
With "a bit like me" I meant the "late manual reader" - in other words:
a.) Unpack the new device
b.) Add power
c.) Turn it on
d.) Try to figure out how it works
....
z.) No other solution - read the manual :)
I'm just kidding - but since documentation is not a kind of Stephen King book normally nobody reads all the chapters.
And there is a very important thing "hidden" in the compression documentation - which I wanna point you to because we talked about view state and compression:
http://www.telerik.com/help/aspnet-ajax/radcompression.html
An other thing - my number one resource are the samples - and some of them have a "performance chapter".
These chapters normally cover the topics where it's about "telerik specific things".
The main part of optimization (from my point of view) is ASP.NET / AJAX - and very little telerik.
Of course there is something "behind" telerik which helps in performance - but that's the part the developers (of the controls) solved.
They took (take) care of optimized rendering - small footprint and so on.
About your three phases of development - I do it in a similar way - with a few changes.
The first thing - I (almost) always have a running thing - "Prototype design" or how ever you may call it.
Other than with your 3 points I start with an "optimized infrastructure" which means that I initially add compression, caching and things like these to my project. The next is what you told - except that web services, ajax calls and (at least a bit) ajax rendering is present all the way in my projects.
The simple reason for this - if I (for an example) know that a Combobox will be filled often there is no need to do it the "classic way" since I already know that it has to be done via a web service and client binding.
I guess (think, hope :)) this "early implementation" saves me some time in the project.
And yes you are right - optimization adds time / cost to a project. So I tend to do the "high end things" on a late stage - sometimes after the initial release - because that's the time where I can measure the (formerly only predicted) "heavy hit consumers".
Or in other words - I can see from site statistics where the reals bottlenecks are.
For an example - if "change password" would take me 3 hours to win 5 seconds - I wouldn't do it - except it is a site where the users have to change their passwords very often.
CONCLUSION:
A lot of possibilities exist in ASP.NET / AJAX and infrastructure (Database Access and things like this).
There are telerik specific things - a good source are the samples.
And - that's the point where no blog / wiki / forum / documentation can help -- there are always "project specific things" which alow to get better performance with a proper solution.
Regards
Manfred
since I don't know you - maybe my tip is wrong - but if you are a bit like me it maybe helpful.
With "a bit like me" I meant the "late manual reader" - in other words:
a.) Unpack the new device
b.) Add power
c.) Turn it on
d.) Try to figure out how it works
....
z.) No other solution - read the manual :)
I'm just kidding - but since documentation is not a kind of Stephen King book normally nobody reads all the chapters.
And there is a very important thing "hidden" in the compression documentation - which I wanna point you to because we talked about view state and compression:
http://www.telerik.com/help/aspnet-ajax/radcompression.html
An other thing - my number one resource are the samples - and some of them have a "performance chapter".
These chapters normally cover the topics where it's about "telerik specific things".
The main part of optimization (from my point of view) is ASP.NET / AJAX - and very little telerik.
Of course there is something "behind" telerik which helps in performance - but that's the part the developers (of the controls) solved.
They took (take) care of optimized rendering - small footprint and so on.
About your three phases of development - I do it in a similar way - with a few changes.
The first thing - I (almost) always have a running thing - "Prototype design" or how ever you may call it.
Other than with your 3 points I start with an "optimized infrastructure" which means that I initially add compression, caching and things like these to my project. The next is what you told - except that web services, ajax calls and (at least a bit) ajax rendering is present all the way in my projects.
The simple reason for this - if I (for an example) know that a Combobox will be filled often there is no need to do it the "classic way" since I already know that it has to be done via a web service and client binding.
I guess (think, hope :)) this "early implementation" saves me some time in the project.
And yes you are right - optimization adds time / cost to a project. So I tend to do the "high end things" on a late stage - sometimes after the initial release - because that's the time where I can measure the (formerly only predicted) "heavy hit consumers".
Or in other words - I can see from site statistics where the reals bottlenecks are.
For an example - if "change password" would take me 3 hours to win 5 seconds - I wouldn't do it - except it is a site where the users have to change their passwords very often.
CONCLUSION:
A lot of possibilities exist in ASP.NET / AJAX and infrastructure (Database Access and things like this).
There are telerik specific things - a good source are the samples.
And - that's the point where no blog / wiki / forum / documentation can help -- there are always "project specific things" which alow to get better performance with a proper solution.
Regards
Manfred
0
Hi,
This is a great discussion. Thank you for joining, Manfred.
I just wanted to quickly mention that we have plans to extend the online documentation and allow community content as well. This will be something like a Wiki where everyone can contribute or comment on help articles. This should be helpful for a lot of people.
Stay tuned for more details in the coming months.
Regards,
Ivo
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.
This is a great discussion. Thank you for joining, Manfred.
I just wanted to quickly mention that we have plans to extend the online documentation and allow community content as well. This will be something like a Wiki where everyone can contribute or comment on help articles. This should be helpful for a lot of people.
Stay tuned for more details in the coming months.
Regards,
Ivo
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.
0
ManniAT
Top achievements
Rank 2
Rank 2
answered on 08 May 2009, 03:39 PM
This sounds nice Ivo,
just a suggestion about it - we once (years ago) made a project for a customer.
It was some "online technical documentation". One of the features has been a "bookmark" or "index" system.
To explain it - you could create an entry in that system - and after it you could add pages (the base unit in the system) to such an entry.
Simple solution - on top and on bottom (we didn't have a context menu at this time) have been two comboboxes (both the same - duplicated just for easier access).
Each combo had the entries you made - and when you selected an entry the current page was added to the selected entry.
For an example - I make an entry "performance" - and then I find somewhere in the documentation a snippet or a tip which I think is relevant for optimizing - I add this page to the "performance index entry".
Later when I look for optimization I can check my "bookmarks" in the section performance and browse through the articles.
This little feature became heavily used and the first update for that project was an extra level of grouping and import / export functionality.
So every user could (for an example) import "John's hydraulic problems bookmarks" and later he could use this bookmarks.
Since every employee has some "favorite machine problems" that bookmarks became the number one feature of the application.
Typical use - you have some electric problem and you know Peter is the "high voltage guy" - so you first check his bookmarks about the problem...
The next extension has been extra data "Short description" to provide tooltips with more information on each bookmarked topic...
Anyhow - back to telerik. Since you are making decisions about the help system - maybe you could also think about some kind of "bookmark system". Maybe simple like VS online help - or a bit more comfortable.
By the way - I don't like the "new" (I guess introduced with VS 2005) help system. I miss the search functionality.
Simply try to search for - more engaging web applications - 500 entries -- reduce it to a whole string "more engaging web applications" - no results :(
There has to be a result - this is a phrase from introduction on RadControls Ajax
As Tony wrote in his initial post - the things (not only his forms) become more and more complex.
I also write manuals and I know how hard it is to provide all important information at every point.
I would say (if the documentation should stay readable) it is impossible to link all those things togeather.
And as I pointed out - often things are very specific and therefore it's impossible to make a note about each and every potentially useful thing in other help chapters.
I'm really curious to see what you will introduce about this in the next months!!
Regards
Manfred
just a suggestion about it - we once (years ago) made a project for a customer.
It was some "online technical documentation". One of the features has been a "bookmark" or "index" system.
To explain it - you could create an entry in that system - and after it you could add pages (the base unit in the system) to such an entry.
Simple solution - on top and on bottom (we didn't have a context menu at this time) have been two comboboxes (both the same - duplicated just for easier access).
Each combo had the entries you made - and when you selected an entry the current page was added to the selected entry.
For an example - I make an entry "performance" - and then I find somewhere in the documentation a snippet or a tip which I think is relevant for optimizing - I add this page to the "performance index entry".
Later when I look for optimization I can check my "bookmarks" in the section performance and browse through the articles.
This little feature became heavily used and the first update for that project was an extra level of grouping and import / export functionality.
So every user could (for an example) import "John's hydraulic problems bookmarks" and later he could use this bookmarks.
Since every employee has some "favorite machine problems" that bookmarks became the number one feature of the application.
Typical use - you have some electric problem and you know Peter is the "high voltage guy" - so you first check his bookmarks about the problem...
The next extension has been extra data "Short description" to provide tooltips with more information on each bookmarked topic...
Anyhow - back to telerik. Since you are making decisions about the help system - maybe you could also think about some kind of "bookmark system". Maybe simple like VS online help - or a bit more comfortable.
By the way - I don't like the "new" (I guess introduced with VS 2005) help system. I miss the search functionality.
Simply try to search for - more engaging web applications - 500 entries -- reduce it to a whole string "more engaging web applications" - no results :(
There has to be a result - this is a phrase from introduction on RadControls Ajax
As Tony wrote in his initial post - the things (not only his forms) become more and more complex.
I also write manuals and I know how hard it is to provide all important information at every point.
I would say (if the documentation should stay readable) it is impossible to link all those things togeather.
And as I pointed out - often things are very specific and therefore it's impossible to make a note about each and every potentially useful thing in other help chapters.
I'm really curious to see what you will introduce about this in the next months!!
Regards
Manfred
0
Hello Manfred,
Thank you for the extra details.
Bookmarking and searching are definitely two of the most important things we will be looking to improve as well as adding community content contribution.
We are currently experimenting with a "new platform" and will provide more details in the coming months.
Best wishes,
Ivo
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.
Thank you for the extra details.
Bookmarking and searching are definitely two of the most important things we will be looking to improve as well as adding community content contribution.
We are currently experimenting with a "new platform" and will provide more details in the coming months.
Best wishes,
Ivo
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.