Archive
Monthly
Go
|
|
DNN Blog
Jun
7
Posted by:
Shaun Walker
6/7/2007
In the 4.5.3 release, a new Search enhancement was introduced which caused a great deal of debate; both in the community and on the development team. Since there are so many factors related to this issue which are not immediately apparent, we decided it would be best to share some additional insight into the dilemma we face.
The enhancement added some extra functionality to the Search skin object which is used in the majority of skins available for DotNetNuke. Specifically, "Web" and "Site" options were added to the Search skin object, providing the search functionality which has become very popular in web sites in recent years. The functionality was added in an extensible manner which allows the "Web" search to leverage any search engine which exposes a public search URL. The default "Web" search is configured to use the Google search engine but an MSN example is also included in the resource file as well.
The ability to control the visual display of the new options is controlled by the standard DotNetNuke skin object attribute mechanism ( essentially you can modify the control declaration in the skin file to include custom values for its public properties - ie. <dnn:search id="dnnSearch" runat="server" showsite="False" showweb="False"></dnn:search> ).
So this all sounds useful, right?
Well the problem is that we enabled the new "Web" and "Site" options by default. As a result, this enhancement had the potential to affect the behavior of existing sites on upgrade ( which we always try to avoid ). Enabling the options by default was in fact an accident in the original 4.5.2 release, but it soon became apparent that simply disabling the options was not a complete solution to the problem. Now some people have already tried to create a big conspiracy theory out of this issue, but the fact is this Search scenario revealed a long-time architectural issue in the DotNetNuke skinning model. Let me explain...
In DotNetNuke, there are a set of skin objects which designers can use to provide an interface between their client-side skin files and the server-side portal engine. For example, we have Login, Register, Menu, and BreadCrumb skin objects which provide dynamic server-side functionality. Now, it is important that designers are able to control the visual display characteristics of these skin objects; therefore, we have robust model where attributes can be customized. The attributes are persisted in the skin file for a simple development and portability model. This all works great for display characteristics where the designer is the real authority on what works best in the skin.
However, skin objects also have customizable properties which control "functionality". In this case it is not necesarily the designer who should be making the decision on what portal functionality should be available. In fact, it is the portal administrator who should be able to specify the functionality they want in their site. So herein lies the problem. There is currently no way for an administrator to control this behavior unless they open the skin file and make their changes manually. Obviously this is far too technical for many administrators and somewhat defeats the purpose of using a content management system in the first place.
In the case of the Search skin object, it really should be up to the Administrator to specify if they want "Web" and "Site" search options. However, if we disable these options by default, there is no easy way for the Administrator to enable them ( as I just described in the previous paragraph ). The reality is that if these options are disabled, it renders the enhancement useless to 95% of the community - as A) existing skins are not aware of the new options and B) many of our users are not technical enough to enable them manually. However for those users who are upgrading and do not want the new functionality, the reciprocal problem exists as well. Dilemma. So given the current limitations, we need to decide which use case would be more common. Would more Administrators like to use the "Web" and "Site" options in their site, or would they prefer for these options to be disabled. In the past we have found that most people want to have "all" the application functionality available - without restrictions. So t this point we are leaning towards keeping them enabled.
So that explains the default settings, but does not solve another problem. Unfortunately, the addition of the new options in the Search skin object can sometimes affect the visual display of some skins. This is especially true where designers have been rigid in specifying the exact size of various objects in their skin. In the vast majority of cases where elastic designs are used, I have witnessed no impact on display. Regardless, we really do not want to impact anyone. As a result, Nik Kalyani has been experimenting with some client-side techniques which would preserve the real estate footprint of the object, while still enabling the new options.
So this has the potential to handle the visual display issue - but not ability for an Administrator to manage skin object functionality. As a result, the other day I decided to write an admin utility which provides this type of functionality. The idea is that the Administrator can choose a skin/container, a specific file, a skin object token, a setting for the skin object, specify a value, and hit Update to activate the new setting. I have a working prototype and we are considering including this as a new module in the Admin/Skins area of the application.
The cool part about this utility is that actually provides documentation for all skin object properties. Help text is displayed in the utility to help Administrators ( and Designers ) understand the purpose of the various settings. The utility also has the ability to generate the XML skin manifest file related to HTML skins - a task which has long been challenging for designers making the transition to DotNetNuke from static web sites.
The lesson in all this is that changes which appear simple on the surface, often reveal much deeper complications you had never considered. And when the changes affect many users, you need to be prepared to act swiftly to fix the problem, but not so quickly that you ignore the big picture.
16 comment(s) so far...
Re: The Great Search Dilemma
Great explanation and nice prototype Shaun. I really like that idea as long as there is a way to "Restore skin default settings" for example in case the Administrator really screws up the display of some Skin designer's skin it can be repaired relatively quickly. I guess a copy or the skin.ascx's could be saved with a .orig extension or something before a modification is saved and then a check for the existance of that file is made before doing it again. If restore default is selected then the .orig file is copied to a .ascx. Some of this could even be done on the install of a skin - though obviously that would not work best on upgrades.
By jwhite on
6/11/2007
|
Thank You and My Feedback
Hello Shaun. First, let me thank you for the cogent explanation and presentation of the challenges/issues this search change presents to the greater DNN community. For my clients, this change was a mess as I had to go and clean up their skins to meet my client's desires of removing it altogether. In the one case the client wanted to keep it, the stylistic attributes were tedious to fix. However, as you correctly pointed out, the trend with website search is to include an option for 'web' and 'site' search. With these trends, we need to keep DNN moving towards accepted methodologies, such as search. I'm heartened by the fact that you and the team are exploring methods to make this a win-win for the community. On the surface, this proposed solution has merit -- and I look forward to seeing this (or other options) presented and implemented. Keep up the good work!
By jgspencer on
6/11/2007
|
Re: The Great Search Dilemma
The Skin manager certainly looks like an excellent way to expose such settings through the Admin interface. I wonder, would it rewrite the original skin ascx file, or do some sort of shadow copy routine as happens with the language files? I run skins at host level and manage the per-portal differences using the portal.css. If one portal wanted a skin option enabled and another portal wanted it disabled, would an Admin-level skin manager like this be able to apply the setting to the host skin just for the one portal?
By robax on
6/11/2007
|
Re: The Great Search Dilemma
This is a great new feature Shaun. It would be nice if you also spent a little extra time and made the AdSense ID a property of the Search SkinObject and then left it blank unless the Administrator wanted to use their own.
By snapsis on
6/11/2007
|
Re: The Great Search Dilemma
Does Site Search provide results that are security role specific?
By pspeth on
6/11/2007
|
Re: The Great Search Dilemma
Sounds like an excellent solution. I really like the Skin Manager module. Your blog is a great example of the complexity in adding New Features into the core. We all love new features, but don't always consider what implications they may really have on suche a large and diverse user base.
By G-Hunter on
6/11/2007
|
Re: The Great Search Dilemma
Thanks for the explaination: things are rarely as simple as it seems. The Skin Manager would be super! I wonder if admin's might get themselves into trouble if making conflicting changes to those the designer relied upon. Also is there a way to may it less constrained? It would be nice to see more than just one Setting Value at a time? This would help me (for one) know what the options were and readily try various settings. Putting this info into an intellisense file for Dreamweaver/VisualStudio woudl also be super!
By VashJuan on
6/11/2007
|
Re: The Great Search Dilemma
With the proposed skin manager a few things to consider might be: Multiple places to configure how search works. The skin manager takes DNN further down the path that site functionality is tightly coupled to the individual skin configuration. Ideally a site admin would want to specify that his/her site has certain features enabled/disabled (eg web and site searches) regardless of the skin that is selected.
By pwh on
6/11/2007
|
Re: The Great Search Dilemma
Good perspective on a limitation faced with Skin Objects: a coding method for developer’s is not available where I can give a portal administrator, via an interface, their own way of manipulating the skin object without custom coding. Sort of a “Settings” for a Skin Object. I’m hoping this enhancement for all skin objects. Best of luck, and again, thanks for all the hard work!
By DougV on
6/11/2007
|
Re: The Great Search Dilemma
First of all, thank you for clearing up many questions that I had... Two things come to mind when reading this post. The first thing has already been mentioned here. (1) It would be nice to put all configurable settings for skin objects in a page in the Admin menu per portal. And each skin object should give the ability to adjust and see all of the settings for that skin object. (2) Along with the log that we see during an upgrade, a helpful feature might be a changes log to show what changes were made since the version of DNN prior to the upgrade. This could be a useful mechanism to notify some users of breaking or potentially breaking upgrades.
By hismightiness on
9/28/2007
|
Re: The Great Search Dilemma
As always, great work Shaun! Is there any word yet on Nik's experiments to preserve the real estate footprint on existing skins?
By SamTanner on
9/28/2007
|
Re: The Great Search Dilemma
As a long-time DNN skin developer, I'm curious to see exactly how the client side implementation works because as soon as I finsished reading your column, I thought to myself: *modify all existing skins.*
In your example above, what if some other token (DATE, USER, LANGUAGE, etc.) was immediately below the web/site selector? Many skins create a graphic "container" around the SEARCH token... these will all break.
To break all those skins over something as trivial as adding a web-search feature - when just about everyone uses a Google toolbar - seems a little unfair. (The search capabilities for DNN have to improve dramatically before I - or any of my customers - would begin using it over any number of search engines that have been optimized for searching the web.)
Frankly, as a skin developer I'm appalled by this decision. As a software developer, I look at each of my skins as a seperate piece of programming. I have over 100 skins - each with 10 - 50 "skin" pages that have to be modified and then re-packaged. and then re-distributed. I can guarantee if your developer community was told that with a new DNN version, all of their code was going to break, we would have a bloody mutiny.
I don't believe I'm being dramatic here. My comments are based on empirical evidence of building skins since DNN 1. For something so unimportant to have such a dramatic impact on your skin developers, I believe the simple solution was to not implement it all - and let people Google.
Having said that, the Skin Manager utility is an excellent addition.
By Rob Poretti on
9/28/2007
|
Re: The Great Search Dilemma
I think footprint of the skin object also needs to be considered. For example in one of my skins, the Search object was placed in the left panel which wasn't sufficiently wide to accommodate the new design. But I like the functionality of the selection. What to do? I had to go in and add a
into the skin object. Seems to work OK but I really an not expert enough to know if I messed something else up by doing that.
The idea of a closable window with the search radio buttons seems a bit clunky to me. But sorry I don't have a better suggestion other than a little routine that would let you design the way the search object would appear - perhaps with more ability to design than what was suggested in the Skin Manager above.
By nubridge on
9/28/2007
|
Re: The Great Search Dilemma
Shaun, great stuff here, I love the new search option for all my sites but one and my client wants me to remove the option to search the web without removing search from the site. I see you notes above but my attempts to modify the skin file have not been fruitful. The prototype skin manager you mention above. Will it be available any time before the next release as a seperate module perhaps? If not is it possible to get some more insight to change the skin file so that we can remove this please. Thank you in advance and great job.
Doug
By DLSWON on
9/28/2007
|
Re: The Great Search Dilemma
Hi Shaun!
The skin Manager would be great. But how can I disable the radio buttons, web and sites in my DNN 4.5.5 installation? I am only the administrator and not a programmer. The skin for the portal our customer have chosen is not compatible with this new functionality and I want to disable it.
NB: I want to keep the search function for the site though.
Can you pleas help me?
By ACtnet on
9/28/2007
|
Re: The Great Search Dilemma
Shaun,
I wonder if you could provide a quick update on the prototype you've teased us with in this blog post, can we expect to see this in v5.0.0? I think this will be a great enhancement however as already suggested, it would be great to maintain the Skin's original settings so that the administrator could quickly revert to the skin's default configuration.
Matt Christenson
By mattchristenson on
4/10/2008
|
|