 |  - for a FREE 30-Day Trial |
 WebProWorld Dev Forum |
Form to Email with attachments script
Hello all, Iam having trouble getting a form to email script that will handle users sending me a file such as a picture.I found a script that looked like it would do exactly what i wanted but when i upload it and set the chmod as the instuctions say it dosent work !
Prepopulating drop down menus using URL
This page contains an Iframe from which a country can be selected to display its corresponding rate and access number. Is it possible to create a URL that will direct customers to this page with a particular country preselected? e.g. where clicking on a link like this:
I am looking for the best multi-file upload script...
I want to build a site much like PutFile.com. I would like for everybody to a member to access this and the memberships are going to be free. All feedback is appreciated.
|
 |
| Recent Articles |
Apple Strikes Back at iTunes Hack
Apple Computer has "closed" (cough) a security hole that allows users to download mp3s from the iTunes Music Store and purchase songs stripped of antipiracy protections ...
Microsoft's Key Windows Architect Defects To Google
According to Microsoft Watch, Mark Lucovsky, one of Microsoft's key Windows architects, has defected to Google.
Simple Solution for PHP Includes
I have recently created my first Php program. I wanted to share with others some of the problems that I encountered, and how I finally overcame these obstacles.
Password Protection with PHP, MySQL, and Session Variables
One of the great promises that actually came true when our Internet-enabled world reached the twenty-first century is efficient customer-to-business interaction.
Intranet Portal Project - RAD or Waterfall?
In this short article, David Viney examines whether Rapid Application Development (RAD) or Waterfall development methodologies should be used during Intranet Portal projects.
Bill Gates Talks Office
Microsoft Chairman Bill Gates spoke at the Office Developer Conference yesterday held at Microsoft's Redmond, Washington headquarters.
Using ASP.NET to Prompt a User to Save When Leaving a Page
Previously I wrote an article titled Prompting a User to Save When Leaving a Page, which looked at how to use the client-side onbeforeunload event to display a confirmation messagebox...
Using Win32 Calling Conventions
When writing code for the Win32 platform, most developers don't pay attention to selecting a "calling convention", and in most cases it doesn't really matter much.
Oracle Unleashes Army of Developers
Oracle CEO Larry Ellison announced the release by 2008 of "Project Fusion," the company's next-generation information- oriented application architecture and application set.
|
|
03.23.05
Intranet Portals – Personalization
And Customization
 By David Viney
The key difference between an (old-fashioned) Intranet and a Portal
What typifies a modern intranet portal is that there is a standardised user interface ("UI") with a built in system for user authentication. In other words, the user signs in to the portal rather than simply accessing it. This brings us to the key difference; an intranet portal knows who you are, whilst with an old-fashioned intranet, the user is anonymous.
If the user authentication is properly linked to your employee data, then the portal will know things like (a) what grade the person is, (b) which department they work in, (c) what location they work at and (d) what job they do.
If the portal authentication is also liked to a metadirectory (along with the authentication for all the other systems the user needs to use in their job) then the portal will additionally know (e) which applications the user needs to do their job and (f) the rights the user has (from their security profile) to access different application functionality.
Finally, if an infocube-based web statistics package has been installed, the portal will know (a) which areas of the portal are accessed by the user and (b) the frequency and depth of that access.
The opportunity to personalise the portal experience
Clearly, given the knowledge above, it is possible to personalise the UI for each individual user. For example, if the user works in the sales function, then the homepage that greets them upon logon could be the Sales team homepage. If they work in Leeds, the facilities link on their homepage could be to maps, traffic, fire orders, etc. about the Leeds office (rather than anywhere else). If their specific job is as a field sales manager, then field sales performance graphs and management dashboard could be displayed on the homepage.
If the user is of a grade that places them on the company insider dealing list, then additional (price sensitive) real-time data might be displayed on the screen (which other users would not see). If statistics tell us that they are not reading important communications, then messages could be served to them that draw their attention to what they are missing. Finally, if they use functionality from three different (legacy) systems to do their job, then these could be brought together and surfaced via a portlet application on the portal page.
The prize is clearly a smoother and more integrated user experience, with key information "pushed" at the user in a way they can't ignore and always no more than a single click away.
The depressing truth about personalisation today
Many portal vendors have undertaken research with their existing customer base to explore (a) how many customers have made extensive use of personalisation and (b) how many surface key business applications via their portal. The results do not make encouraging reading (with less than 20% achieving much beyond what Plumtree call "the empty portal").
This prompts an obvious question. If the benefits to the user of personalisation are so obvious, why have companies not taken advantage of them? In fact, based on my experience, there are multiple reasons not to personalise, which I group into "bad" and "good" reasons.
Bad reasons not to personalise
There are a number of typical failings that tend to stem from a lack of courage, poor understanding or personal prejudice:
1) Failure to link through to employee data and/or a metadirectory
This can be due to a number of factors, including (a) the costs of software seen as too expensive, (b) a perception that implementation will be too difficult or prone to failure, (c) a lack of confidence in the quality of employee data and (d) realising too late that this work is important and having failed therefore to include in project scope or business case costs
2) Failure of vision and/or lack of confidence in personalisation benefits
Typical problems include (a) a lack of experience of using portals and thus a lack of awareness of the possibilities, (b) a nostalgia for the old-fashioned style of intranet navigation, (c) an unhealthy focus on the intranet simply as a communication channel, rather than as a business tool and - perhaps most interestingly - (d) a perception that personalisation is synonymous with (or otherwise encourages) individuals failing to observe and comply with single, enterprise-wide processes and policy.
Sweet deals for iEntry members! Out with the old... if you have equipment that qualifies for trade-in,
in with the new. Get a discount of up to $720* off the Web price on featured IBM(r) ThinkPad(r) notebooks.
And ask about our battery offer. See full details of offer.
Hurry! Offer valid from IBM in the US only through 3/28/05 or while supplies last. |
|
Good reasons not to personalise
There are actually several valid objections to personalisation, which you would ignore at your peril. The two most notable are:
3) The whole is more than the sum of the parts\
Many portal projects are built on the concepts of (a) increased knowledge sharing between teams, (b) better awareness of the "big picture" of what is happening in the company and (c) a sense of belonging to a single, enterprise-wide community. By personalising teams and individuals into "ghettos" where they only see information and applications directly relevant to them, the opportunity is lost to have them explore the intranet presence of other colleagues.
4) Log-in as a barrier to user adoption
A (valid) concern that requiring people to log-in each time they access the portal will act as a deterrent to them doing so, thereby reducing the portal benefits through a reduction in intranet usage. This has lead to some customers disabling the log-in feature! Of course, such problems can be overcome through the implementation of a single sign-on application, where rights to access the portal (without a separate log-on procedure) are granted when the user logs onto the network. However, companies often fail to plan or budget for such changes.
Read the Rest of the Article.
About the Author:
David Viney (david@viney.com) is the author of the Intranet Portal Guide; 31 pages of advice, tools and downloads covering the period before, during and after an Intranet Portal implementation.
Read the guide at http://www.viney.com/DFV/ or the Intranet Watch Blog at http://www.viney.com/intranet_watch. |
|
