too many input fields on a form - user-experience

I have a form which has about 15 fields a user has to input..I'm looking for a way to not scare the user's off.
I wanna see if someone implemented forms with too many fields differently or if anyone has any ideas

If not all the fields are necessary because they depend on some choice, you could only display the relevant fields once the choice has been made. You could also visually distinguish non-mandatory fields so that it's clear from the outset how much work has to be done by the user and how much is optional.
If everything is mandatory, then you could either go the Windows way and show tons of small windows in sequence and annoy everyone who just wants to get it done, but you'd not scare people who get scared by seeing lots of forms - a page counter is crucial, though. However, you could start with a small wizard view, but immediately offer an "advanced" option that would allow those who want to show everything at once, while still offering a guided tour as the default.

Try to keep it in steps - maybe organize about 3 different pages filled with the forms.
Example: Contact info, they hit continue. Then they hit another page, except with the forms for ordering an item. Then the third page is for payment fields.

Related

Sharepoint 2010 - Pass "u" parameter to advanced search

The scenario - I am building a site to house a number of reports - thirty or so subsites under a main web for different report categories, and several libraries in each site, one for each separate report. In total, about 600 reports (libraries) across the thirty report categories (sites). This design has been decided on, and cannot change.
I plan/want to have a single advanced search page to search all the reports, using various custom metadata columns. That bit's easy, I can do that out of the box.
One of the most important search criteria is which report on which to search, of which, as I mentioned, there are many. The dictate is to make the report type added "invisibly" - they will select the report category, then the report type, and THEN get presented with the search page. The search should "know" which report is being searched on.
Scope selection is not a viable option, as there's too many libraries, and more will be added as new reports are created.
Now, I can get the results I want in the results if I add the "u" parameter to the URL as in;
results.aspx?k="RunDate=1/23/13"&U=http://site/report_type/library"
(address left unescaped for clarity)
My challenge is finding a way to feed that parameter TO the advanced search, and get it to tack it on to the end of its generated query.
I'm confident it can be done with only a little fidgeting to the webpart, but I need a bit of a shove in the right direction.
Or, as always, if y'all have a more brillianter idea, I could do that.
Now, I have a second issue where the different reports have their own varying set of metadata columns, and they only want the RIGHT ones to show up for each report, but one crisis at a time.
EDIT - upon further research, it seems I can't extend the advanced search webpart, as it's a sealed type. Has anyone either a way around that, or have a third-party advanced search page that I CAN crack into?
I was able to find a solution to this issue by overriding the JavaScript function NavigateTo(url) which is responsible for the redirect. My solution can be found here
What you are actually asking about is a contextual search box, as the u parameter resembles the contextual search scope.
I'm not sure that the standard search box can be configured the way you want it to, so it always adds the query string u=<current url>. I think you will have to resort to some (even if simple) code.
An example you can find here: Create a SharePoint Contextual Search Box in a Content Editor Web Part.
Of course you could do the same thing with server side code, but as you only want to add a querytring parameter, JavaScript should be enough.

Multiple Edit forms in Sharepoint 2007

I've got a form that gets filled out in stages so I wanted to direct users to a secondary edit form part way through the process. Is this possible?
Hide and reveal using JQuery on the editform.aspx would be my initial choice. I've done this type of work for a very well known bank and it worked very well. Single form with different sections of the form to fill in dependant on the answers provided (and the user group membership)
If you actually want to maintain two lists and hence two forms and redirect between the two - I would look into changing the "source" querystring parameter in the editform so that on completion of the form, you get directed to an alternate location. Not tried it but it would be a sensible place to start looking.

Saving to multiple lists from 1 sharepoint 2007 list form

I have a request form I'm working on, wherein different departemnts need to be able to update it. To minimize overlap and lost changes I'd like to be able to submit data from the new form to different lists, but I cannot find a way to do this.
Does anyone have any experience trying to do anything similar?
If you're familiar with JQuery andSPServices I could envisage a way to do this.
In the EditForm.aspx, add the JQuery and SPServices libraries. using the $.(document).Ready function, I'd do a quick item update with the SPServices and just copy a column with the same data, so in effect no change looks to have taken place. I'd add in the edit comments something like "Pseduo checkout to [name], [date_time]".
Then allow the user to edit the form as normal but in the code you've added, you trap the PreSave Action and check that the person trying to do the save is the same as the last modified - if it is, save as normal, otherwise, return false on the PreSave and it will be denied. When you actually allow the save, set the edit comments to something sensible.
To complete this, check before doing the pseudo checkout, that the last comments don't contain the psuedo checkout phrase so that you can prevent anyone opening/editing the form whilst somebody else is in the middle of an edit.
This gives a cheap and relatievly easy to implement Check-In/Check-Out for a list. Not perfect of course but should work well in most scenarios (not in datasheet though, so you might need to prevent that type of edit).
If you have two lists would you not then have the problem of potentially two requests for the same thing?
Does none of the version control options for the list solve the problem of potentially multiple concurrent editors?
While SPService is certainly a solution, but you will have to build a UI of ur own.
Try writing a event receiver, which can copy over item to another list as soon as it is created.
It will be nice if you can tell why you really want to have a copy of item in another list
i.e. Auditing purpose etc. , you can get a perfect solution for this in Forum

Multiple Sharepoint Forms

I am trying to split out what I originally wanted in a single form. The downside was that I wanted to keep multiple lists and I found that I could not use a single form with multiple lists.
What I am trying to do is to keep my customer information in a separate list/form so I can re-use it in a different application as well.
What I would like to do is give a picker to pick the customer from a list, and if the customer is not listed to allow the creation of a new one.
What I am wondering is how I can leave the main form, create the new customer, and then return to the main form but with the new customer information passed to the new form as selected. In ASP.NET one of the ways I would do this is through the querystring, but I am not sure if that is doable or preferred in Sharepoint.
Any thoughts or links to tutorials would be great.
Please keep in mind that due to access/security limitations I am trying to do this strictly through the browser and Sharepoint Designer.
Thanks!
With your access limitations, I don't see a solution that will allow the refresh of the original form to get the new data. You may be able to hack in some JQuery stuff to do this, but I just don't see it being an easy/value-for-time thing to do.
You may just have to allow the form user to save the form without customer info and come back to it.
A list view can then highlight forms with no customer info. This all depends on the usage scenario.
You can use the Source query string parameter to get you back to the original form after completing the new customer form. However, unless you add some code (either javascript or server side) you won't get the id of the new customer.
The best option is probably using jquery and the sharepoint web services. It's quite easy if you start with the right scripts, and you can do something like your original plan - make a simple form in a jquery ui popup.
You can also use javascript to manage linking between multiple forms, but you need to be careful about clearing out already entered form data.
Another option would be to edit dispform.aspx and add dataviews for other lists, along with appropriate add buttons, and add javascript to the new customer form that sets the value of a connecting lookup field. However, that tends to require quite a bit of messing about with list guids and other undocumented bits.

How can we restrict the user from saving a web page?

How can we restrict a user from saving the page?
Please provide some tips to disable File->Save and View Source options
EDIT: Obviously it can't be done, and probably shouldn't be attempted. But possibly a more interesting variant on this question is how can we make is sufficiently hard for a user to save a page in a usable format such that it is not worth their while doing so? The question doesn't pose a value, but say we were protecting an article subscription site where the user is paying a few hundred dollars per annum for continued access to text.
Since the page has been sent to the client, there will always be a way to get that information. Trying to stop a user from doing this will only frustrate them.
The only way to have a user not be able to save a file is to not send it to them.
While the best answer is "Don't do this," there are ways to make it more difficult for them. And since the point of this site is actually answer the question even if it's bad, here is the best way:
First you'll need to have the page open in a new window where you turn off the address bar and toolbar and everything else. That will make it so the user can't easily get to the File menu at all. To do this you'll need a "splash" page that the user loads to and then when they click a link, it opens the popup that serves the main content of your page. Details on how to create popups without things like the toolbar are here:
http://blazonry.com/javascript/windows.php
Then you'll want to add some javascript to each page that prevents the user from right clicking. Here is one method:
http://javascript.about.com/library/blnoright.htm
Finally, if it's your Javascript code that you don't want to be seen, then obfuscating your code is a pretty effective way to do that. They can still see the code if they have much know-how, but the obfuscated code would be a gigantic pain to actually interpret. There are lots of obfuscators out there; here is a free web-based one:
http://www.javascriptobfuscator.com/
This is far from foolproof. It will stop all "casual" users, but any power user will probably be able to easily figure out a way around it. Still if the idea is to at least prevent a good majority of it then this should suffice.
Update for updated question:
To address your new expanded question, I would say the best way to accomplish what you're saying is to use a format that supports DRM. Adobe Acrobat would probably be the best choice because almost everyone has the reader installed. You can prevent PDF files from being saved to the computer so that they can only be loaded from the webpage by a logged in user. The user could still do a screen capture of the document itself which I don't believe is preventable (unless Adobe Reader has some security in place for this, which they might) but it should be sufficient security for most uses.
Don't do it.
Seriously, if the user can see the page in their browser they can see the source code and/or save it to their computer.
You are fighting a losing battle here.
What about the browser's cache? It can be saved from there.
What about a print screen? That could also save the page.
The only way to prevent a user from saving something is to not show it to them in the first place.
It's really a waste of time and resources to try and do this in html as any method you use can be trivially circumvented.
Instead I would use some other technology to display the data - you can never get around a screen capture. but if you're for instance displaying text and you want to make it hard for the use to save that text for use elsewhere then possible options include
PDF - which can disable save and print. There are extensions to most popular web languages that will write a pdf on the fly. Indeed you might be as well just to go down the DRM route with Adobe and embed a document
Flash - most probably via Flex which could be used to write a general-purpose app to display text and images. The advantage of Flash is that it's easier to set up links than pdf.
Or something else, a custom java applet, or even a vrml plugin and display the text in 3D!
In all cases you could display text against a disruptive background to make OCR more difficult, and images could be watermarked. However nothing is going to stop a determined and resourceful viewer, although you can possibly make it sufficiently hard that it's not worth their time.
The least you can do is... the content is generated dynamically by Javascript. In that way, they cannot simply save it. Of course, in FX, they can still view the generated code and then copy&paste. however, normally people cannot save the page.
It shouldn't be an issue, but if you really don't want a user from seeing your code (javascript, css or html) for some reason, than you could use some obfuscation tool which makes the code less readable.
Try javascript "encoding" and obfuscation.
Something like
if(document.location == 'mydomain.com') {
content = getAjax('mycontent.xml');
// content will hold something like 72, 94, 81, 99, ... - encoded ASCII codes
document.write(String.fromCharCode(content));
}
It will always be possible to save the page, but for non-technical guys it will be harder to make it work.
There are 2 protections
domain name
converting ASCII
It's only pseudocode, but I think you get the idea.
add these to code sets in script tag
document.addEventListener('contextmenu', function (e) {
e.preventDefault();
});
document.onkeydown = function (e) {
return false;
};
I'd like to add one more method which, imho, is hard to circumvent: Ctrl+S! (for me, Apple+S)
how can we make is sufficiently hard for a user to save a page in a usable format such that it is not worth their while doing so
Nothing hard: add on every page: "Personal property of John Stealer, company Zetabeta, paid with credit card 756890987654, billing address ..., subscription expires 12/20".
This is an "extended text format" that I just invented... it has an amazing property: though it looks like a regular text, user is much less willing to print it out and give to others...

Resources