When you develop web applications, especially ones that deal with a good amount of data management (e.g. contacts, addresses, orders and so forth), do you usually create the interface as in-place edit or make a separate "edit" page (and a view-only page)?
Why / What is the advantage of one over the other? I'm trying to make a decision on my own project which has such data management and I'm not sure which way to go.
I think inline editing makes sense when the 'cost-of-effort' of making the change is relatively low.
For example, changing a description on a photo is something that's pretty easy to do, there's little risk if its not exactly right, and the user expects to do it right in context with the picture they're editing. In that case, inline makes sense to me.
On the other hand, in an application where the user needs to be helped or guided through a process, or the change means major changes in billing/shipping/account status. It may make sense to have a separate page to help them understand the full ramifications of their actions.
for things like settings where the main use for viewing the page is to edit it, inline makes sense.
After that, it's more about the usage. If people are constantly editing them then it should just be inline. If it's for say user details, where it is mostly read and sometimes changed, this is what I do:
The page is viewed without editable boxes.
If the user wishes to change some information, they hit an edit button
The same page is shown but with editable fields and cancel / submit buttons.
I achieve this by having the view decide based on a value in the property bucket which version of each field to show, which is set by the action (MVC)
EDIT:
Sample as requested (untested)
In the controller (castle monorail), let's say CustomerController:
public void View(int customerid)
{
PropertyBag["customer"] = Customer.Find(customerid);
}
public void Edit(int customerid)
{
PropertyBag["editing"] = true;
View(customerid);
RenderView("View");
}
in the View (brail):
<th>Name:</th>
<td>
<% if IsDefined("editing"): %>
<input name="c.Name" value="$customer.Name" />
<% else: %>
$customer.Name
<% end %>
</td>
I would say that you should use in-place editing when editing the data is straightforward and simple (idiot-proof). It should be no more complicated to the user than selecting text in a word processor and typing over it.
If you need/want to show labels, instructions, error messages etc, you should probably use a dedicated edit page. Or find a clever way to do this in-page.
Also, sometimes you don't show exactly what the user entered. For example, you show the user's age, but when editing it shows the birthdate. Then I would suggest that you use an edit page, since it could be confusing to the user.
Related
Like the topic say I want to overwrite/change the "Menu Manager: Edit Menu item" layout. To illustrate my question:
In the picture whiche is shown I want to change the labels: Layout, Option, Integration.... and add some other options to it. How can I do it? Or is this even possible?
In order to change the text, simply use language overrides, google is your friend.
In order to add functionality, let's first of all explain what we're talking about to ensure we're on the same page.
Joomla components have views which can have one or more layouts, i.e.
/components/com_content/views/category/tmpl/ contains two layouts, blog and default.
A layout can additionally contain an .xml manifest (in our case, blog.xml and default.xml) allowing us to create a menu item for the specific view/layout combination. The .xml file contains the parameters that the user will set, you can add your own as well.
When you want to change Joomla, usually there is a way to do so without touching the core, which would be pretty bad, as any Joomla! updates would break your work.
For the view layouts a special feature called template override was developed, which allows you to create an alternative to the view layout in a safe place (under your template folder, in this case your admin template), and this is the most elegant and effective way to achieve your result.
Beware though, you are just creating a layout, most likely you will want to add functionality, if it's complex you might be better off creating a dedicated component to keep the code clean. Or you can just put all the logic in your view, query the database from there. But in this latter case, get paid, and run away. Never answer the phone to the customer again.
A final alternative is to write a system plugin that will manipulate the page markup after it was generated in the event onAfterRender(). This is a simple and good approach if you only want to add a button or make minor changes, but if you do anything more than that, see the above advise about running away.
I have a shopping cart I want to embed in a widget/iframe on other users sites, I see three ways of doing this each with drawbacks. Here are options from estimated most to least work.
Recreate interactive shopping cart UI in javascript widget then pass values to server script with AJAX, variables are passed to the main site, when user clicks "checkout" the user is then redirected to main shopping cart site with variables populated from what the entered in the widget.
pros: complete experience
cons: most work to complete creating UI and AJAX request.
Somehow detect if user is coming to shopping cart via iframe, if this is the case have alternate code that opens new window when user clicks "checkout" redirecting user to secure page and getting variables from cart via AJAX to populate final checkout.
pros: mid amount of work, must do AJAX request to get variables from shopping cart to populate final checkout
cons: can we easily detect if site is being accessed from a user within an iframe on another site?
complete entire checkout process inside iframe/widget.
pros: least ammount of work, just embed cart in iframe
cons: will not show https in browser user may be reluctant to purchase
What is the best option?
If you could provide a bit more information, maybe I could offer you an even better option. For starters, what have you built this application with (languages/framework)? Also, would you say your application's functionality is similar to Shopify's in that you allow users to host e-commerce sites through your service? If not, tell us a bit more about your application.
Here's a quick response to the options you provided.
option 1: the only real option as I see it. Whether you're embedding the shopping cart in specifically an iframe or rendering it onto the user's page as part of a template, you should be navigating the customer away to your main site to complete the checkout process. Or at least give them a lot of screen real-estate to work with (a sizable modal for example).
option 2: is messy. You can tell if a request is coming from a remote form (like an iframe) by appending url parameters. But taking the approach you're suggesting with this doesn't make too much sense.
option 3: too heavy unless you take a modal-approach like what I mentioned in response to option 1.
That being said, if you are building an application like Shopify, you should be able to build a template for each user's website that has a section dedicated to displaying a shopping cart pertaining to the current customer's session. No iframes or widgets necessary with this approach. But again, it all depends on the use cases of your application.
If your only concern with Option 2 is detecting if your content is being loaded within an iframe, you can do that with JavaScript by using "top.frames.length" or "top === self."
For example, you could show or hide different conditional form content, or a different submit button, using the following:
if (top.frames.length == 0) {
// Show content if not embedded in an iframe.
document.getElementById('embedded-content').style.display = "none";
document.getElementById('unembedded-content').style.display = "block";
}
else {
// Show content if embedded in an iframe.
document.getElementById('embedded-content').style.display = "block";
document.getElementById('unembedded-content').style.display = "none";
}
As you've stated, the first option is the best in terms of user experience and the most likely to achieve the highest possible conversions. How much better the conversion is compared to the next best solution cannot be objectively measured, as it involves recurring customers, your own brand name, the kind of products, etc. Since the conversion rates will directly affect you (and your company), it's wise to make an estimate first to see if your efforts spent will be worth it in the short and long term.
The second option is the sweet middle ground; you still get brand recognition and customers will have some security reassurance (via address bar); (i)frame detection is easily done by a simple JavaScript comparison: top === window. However, you're losing the continuity and hence likely lose some conversion. If this risk is manageable, I'd go for this option in the short term.
Not being able to see the security certificate directly via the green lock makes the third option the least desirable. However, not all is lost; by clever use of imagery you can still gain some trust with your end-user, as outlined in this image, which is part of a great article from Smashing Magazine.
Your decision should be based on:
what can be done in the short term
what should be done in the long term
how important is secure visual cues to my potential customer
time / money spent on either solution versus revenues (break-even analysis)
I am writing a cms (on .net) and have structured the whole page to work client side.
There is a treeview that lets you add/remove/move items and define their names in the languages defined. For each language I save the names of the category defined, but when there is HTML content associated with it, i fall into the JavaScript serializer problem that finds the content too long to be serialized.
What would be the best approach to make sth like this work. Shall I change everything to work with postbacks, or try to manually call _doPostBack for the editor content (which I don't want). Thank you in advance.
I guess would be great to make auto-save with time interval which will submit only diffs between current state and previous save. It will do the key if the user will edit it manually, not for copy/paste, of course. It is if we talk about really big data that we need to save.
Otherwise need to find some ways to compress the data before submitting: json+base64, etc.
The default scaffolded views generated by ASP.NET MVC 2 contain links such as:
<%: Html.ActionLink("Back to List", "Index") %>
<%: Html.ActionLink("Create New", "Create") %>
These links are perfect if I came to this page from that same root. But for example, if I have Orders and Persons and I navigate to /Orders/Edit/17 via /Persons/Orders/3, then 'back to list' returns me to Orders root not Persons root, where I want to go, because the 'Edit Orders' view only knows about orders. This makes the navigation awkward and breaks the flow..
I want to reuse the same 'Edit Orders' view regardless of where I came from, but I'm not sure how to pass this information.
I know it's possible to pass parameters like /Orders/Edit/17?myparam=myvalue but will this limit my choices later on if I need to pass parameters which indicate Sort/Filter order for grids?
What is the preferred way to pass a return/origin location to my view so that it can render the links properly? Otherwise, how can I call the view differently from the controller?
EDIT:
For a clean solution, see THIS POST
Passing in parameters through the querystring will not really limit you as long as you don't use the same names. There is a size restriction on querystrings, but you'll probably not hit it.
That's basically how I do it. I'm curious to see what others answer.
This functionality seems like something that should have been accounted for in the framework; it seems fairly hacky to have to specify these parameters because you'd have to do so for every level of navigation.
Why? back is something that belongs in browsers, along with history. Its been like that for a while, why should the framework need to handle that?
What you need its not the norm.
Additionally, you are responsible to keep your code dry. You can definitely handle it in a way that all the repetition you have is the name of the function you are calling.
the problem I have is that I have two sets of values in a drop down list. If type 'A' is selected I want a text box to be populated with a value from the database and be read only. If Type 'B' is selected the box is to be empty and editable.
My original code is written in jsp/struts and I have sort of achieved this by using
onchange="javascript:submit()" to reload the page, but this has the obvious drawback of saving any changes you have made which means you can't really cancel.
I also have other problems with the serverside validation due to this method.
Is there a way of making a jsp page reload on change, that way I could write javascript to change the way the page looks according to the values held in the session. That way the save/submit function will only be called when the page has properly been filled out and the server side validation will work as designed.
I know that this is something that AJAX is good at doing but I am trying to avoid it if possible.
AJAX is your only other option my friend, unless on the original page load you load all the other possible values of the Text Box so you don't need to go back to the database. Well, you could try putting the text box in an IFRAME, but you will probably run into more problems with that approach than just going with AJAX.
Without AJAX what you are asking is going to be difficult. Another option (which is ugly) is to write out all possible values for the second list box into a data structure like an array or dictionary.
Then write some javascript to get the values from the data structure when the user selects from the first list box. The amount of javascript you will have to write to get this done and to do it correctly in a cross browser way will be much more difficult than simply using AJAX.
Not sure why you'd try to avoid AJAX in today's world, the JS libraries out there today make it so simple it's crazy not to try it out.
I just had to replace a page that was written as Vincent pointed out. I assume at the time it made sense for the app, given the relative size of the data 4 years ago. Now that the app has scaled though, the page was taking upwards of 30 seconds to parse the data structures repeatedly (poorly written JS? maybe).
I replaced all the logic with a very simple AJAX call to a servlet that simply returns a JSON response of values for the 2nd drop down based on what was passed to it and the response is basically instant.
Good luck to ya.
One way is to change the form's action so that you submit the form to a different url than the "save" url. This lets you reload certain aspects of the form and return to the form itself, instead of committing the data.
<script>
function reload() {
document.forms[0].action="reloadFormData.jsp";
document.forms[0].submit();
}
</script>
<form action="saveData.jsp" method="post">
<select id="A" name="B" onchange="reload()"><!-- blah --></select>
<select id="B" name="B"><!-- blah B --></select>
<input type="submit">
</form>
If I understand you correctly, that you want either a dropdown (<select>) or a textfield (<input type="text">) depending on a choice (typically a checkbox or radiobuttons) somewhere above in a form?
I that case you may need to handle the two types of input differently on the server anyway, so why not have both the selectbox and textfield in the area of the form with different names and id and one of them hidden (display = none). Then toggle visibility when the choice changes. On the server you pick eiter the selectbox or textarea input (wich will both be present unless you disable (disabled="disabled") them too, wich I think is uneccesary) depending on the choice input.
Of course if you expect that the user usually just need the text-input, and a few times only, needing a massive list; it would be better to use ajax to retrieve the list. But if it's the other way around (you need the text-field only occationally), as I assumed above, it will be faster to have both present in the initial form.
If the drop down only contain easily generateable data, like years from now to houndreds of years back it could even be much faster (requiring less bandwidth on the server) to generate the data client side using a for loop in Javascript.
I know a taglib that can fit to your problem:
AjaxTags.
I use this taglib in my J2EE projects and it is very simple to integrate it into web applications.
This taglib give you several tags designed to execute AJAX request in your jsp files.
Here is the description of each tags: http://ajaxtags.sourceforge.net/usage.html
The tag which will help you is the ajax:select tag. It allows you to populate a select tag which depends on an other field without reloading the entire jsp page.
If you more informations about it, ask me and i'll try to answer quicky.
Along the lines of what Strindhaug said, but if you need dynamic data:
Could you have the backend write JS into the page, and then the JS would change the form as required? The backend could propagate some variables for descriptions and such, and then the JS could change/update the form accordingly. If you aren't familiar with this, libs like jQuery make things like this easier and more cross-browser than rolling-your-own (at least in my experience).
Aside:
If you're not using AJAX because it was hard to code (as I didn't for a while because my first experience was from scratch and wasn't pretty), as others have said, libs like MooTools and such make it really easy now. Also, there is not shame in using AJAX properly. It has a bad rap because people do stupid things with it, but if you can't simply write premade values into the form or you have to do live look ups, this is one of AJAX's proper uses.