Wanting to check if I missed a setting somewhere, or if I'm just using the product in an unintended fashion.
I've created a prototype based on an existing site, and am using states to mimic functionality, along with tabcontrols and the like. When the end-user is marking up the page, and then changes tabs, or clicks a button to change states (but stay on the same 'screen'), the drawings from the end-user remain in the same spot. The issue is that if the user highlighted or crossed something out, it interferes with the new state.
Is this intended, an undocumented feature, or am I just expecting a little too much? This may be a dealbreaker for us using this tool in our organization if we can't either resolve or have a reasonable workaround. I'm open for suggestions.
I believe feedback is stored at the 'screen' level not the 'state' level
I suppose you have 3 choices:
Instruct your users to list the steps they did before they add their feedback
Change your states to different screens instead (they can still look like the same screen for the end user, but in your application they will be different screens)
Have your user submit screen shots instead of just .feedback files
The second option will allow you to organize your feedback better.
In short I think you're expecting more than they offer ;)
Related
I'm working on web application and our team wants to make it more accessible. In particular, we want to do a better support for people who can't see (using screen readers).
One of the popular solutions is NVDA. After reading their doc here, it's not clear - do they support a custom markdown?
Can I use some attributes/tags/metadata so that NVDA read stuff differently? For example:
Google will be read as 'Google'. Can I decorate it in some way, so that it will be read as 'Link to Google'?
Thank you.
There is no such thing as a custom mark-up for screen readers. Well, there is something like that, I'll tell you about it below.
Basically, when you try to make your web site more accessible (a very good thing to do, btw!), you should minimize your impact on screen reader users. By "impact" I mean that your goal should be that your blind user would see just the same thing as a sighted user, but as the web site developer, you give him/her this ability to see, navigate, open, click and so on, and so forth.
There is a way to customize the layout, though. It is called WAI-ARIA. You can do lots of crazy (and smart) stuff with it, it is great and mighty, but the first rule of the fight club, I mean, WAI-ARIA practices is:
If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property
to make it accessible, then do so.
— from here.
I.e.: If you can not to use ARIA, don't use it.
Let's take your example with the link to Google: you want your blind user to see the "Google" text and to understand that it is a link, right? Well, I'll tell you what you should do to achieve this. And you need to do... drum roll... nothing! NVDA, or JAWS (which you definitely should test with, it's a major player!), or TalkBack on Android, or VoiceOver on Apple devices, will say: "Link Google", or "Google link" (depends on the screen reader and on particular user's settings). that's all.
Of course you might have done this (but don't do it in any way!):
<span aria-hidden="true">Google</span>
See how crazy (and mighty!) it is? Thus you're telling the screen reader that you need your custom text to be read and hide your main link text (just in case; I've just tested with JAWS, everything works even without the aria-hidden attribute, so it's merely for an example).
However, if your link is a span with some fancy styling, ARIA is your everything: you just say <span role="link">, and your users will get a pleasant experience instead of trying to find which word to click.
And a last example: in Bootstrap there are lots of decorations like
<i class="fas fa-arrow-up"></i>
If they are on a link (and mostly they are), some screen readers such as JAWS would report two links, one with text, and one empty, just "link". In those cases it is really good to hide this stuff from screen readers:
<i class="fas fa-arrow-up" aria-hidden="true"></i>
NVDA, like JAWS, VoiceOver, Talkback, and several others, is a screen reader. A screen reader is software that a low-vision or no-vision user will use to access their computer. If you write semantically correct html, then your app will automatically work with a screen reader.
To create semantically correct html, the W3C has created a set of guidelines, call the Web Content Accessibility Guidelines (WCAG) that outlines things you can do to improve your web application to make it available for the greatest number of people.
It includes things like having alternate text for images, having labels for form elements, using well-worded text for links, and using the proper html tags for semantic elements, such as <h1> for headings, <ul> for lists, <table> for tables of data, etc.
When native html semantic elements can't be used, for whatever reason, then there are ARIA attributes and roles that can be applied to give screen reading software a clue as to what type of object you are trying to convey.
So, there is no markdown for NVDA or any other screen reader. You just have to be smart in your use of html.
I am building a brand new website in Sitecore and I am looking for advice on the following scenario:
My site has 2 version of its homepage. Both are quite different. The layout is the same, but most of the components and sublayouts on it will change depending on whether the user is logged in or not.
Does anybody has a suggestion of a good practice, or way to do that in Sitecore? My basic requirements are, have a single URL for both (the website root, it is a homepage) and do not harm the content author experience.
My thought so far was:
Use of personalization to control the components to be displayed (Concerns: performance and the content author experience he woudnt have to change component by component to see both versions)
Use of two item in the tree and intercept a pipeline to resolve the right item at the right time (Concerns: the content author would have two home items to maintain *not actually a big problem)
Does anybody has any other approach or considerations on those I listed?
Thanks
An alternative solution would be to make use of devices, and use a pipeline to switch devices if the user is logged in.
Set up your Device in Sitecore to use the default layout as a fallback so it does not affect other pages in your site (and they continue to work as expected). You are then able to set different sublayouts and components for that Item (directly or in Standard Values for the template) for each device. You can make use the VaryByDevice caching option to make better use of the Cache.
Your content editors can also switch between the devices easily in the Page Editor from the ribbon. Any further customization you need in other areas of the site, such has switching out a single component, can be run using a Personlization Rule taking advantage of "where the current device compares to value".
It does sound like you have the need for personalization based on authenticated status, so I would recommend staying with the built-in personalization interface to avoid confusion. Authors will have been trained during Sitecore training on how to use personalization, and introducing an alternative method for accomplishing the same thing could lead to a less-than-optimal experience for the author.
To address your concern of the author needing to view components by toggling each one, I would recommend installing the Experience Explorer module. You can create presets that meet your rules on your presentation and then the author can preview the site for different 'experiences'.
If you have a single URL for the home page, it is more straight-forward to go with a single item, so I would definitely advise against having two home page items that are being resolved by the same URL.
You mentioned a concern for performance, so I would recommend you making sure that you enable your sublayout caching settings. In your case, varying by Data may be the way to go, given you would personalize with two sets of datasources.
In the past I have used the following crude technique:
Make two components, one for "logged in" and the other for anonymous.
Each rendering has just one line, a single placeholder, either:
<sc:placeholder key="logged-in" runat="server" />
or
<sc:placeholder key="anonymous" runat="server" />
For "logged in" I make a personalisation rule which hides the component if anonymous, and for the anonymous component I make a personalisation rule which hides the component if the user is logged in.
I then nest all the components under the correct placeholder key.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am currently building a registration page where if the user leaves, I want to pop up a CSS box asking him if he is sure or not. I can accomplish this feat using confirm boxes, but the client says that they are too ugly. I've tried using unload and beforeunload, but both cannot stop the page from being redirected. Using those to events, I return false, so maybe there's a way to cancel other than returning false?
Another solution that I've had was redirecting them to another page that has my popup, but the problem with that is that if they do want to leave the page, and it wasn't a mistake, they lose the page they were originally trying to go to. If I was a user, that would irritate me.
The last solution was real popup window. The only thing I don't like about that is that the main winow will have their destination page while the pop will have my page. In my opinion it looks disjoint. On top of that, I'd be worried about popup blockers.
Just to add to everyones comments. I understand that it is irritating to prevent users from exiting the page, and in my opinion it should not be done. Right now I am using a confirm box at this point. What happens is that it's not actually "preventing" the user from leaving, what the client actually wants to do is make a suggestion if the user is having doubts about registering. If the user is halfway through the registraiton process and leaves for some reason, the client wants to offer the user a free coupon to a seminar (this client is selling seminars) to hopefully persuade the user to register. The client is under the impression that since the user is already on the form, he is thinking of registering, and therefore maybe a seminar of what he is registering for would be the final push to get the user to register. Ideally I don't have to prevent the user from leaving, what would be just as good, and in my opinion better is if I can pause the unload process. Maybe a sleep command? I don't really have to keep the user on the page because either way they will be leaving to go to a different page.
Also, as people have stated, this is a terriable title, so if someone knows a better one, I'd really appreciate it if they could change the title to something no so spammer inviting.
As soon as I saw the words "prevent the user" I started to wail in agony. Never prevent the user, only help them.
If they see your registration page and run off, that's their choice. Pop up a javascript confirm box if they've already filled in some data (because they might be navigating away accidentally) but leave it at that. If they haven't touched the form, leave them alone - they don't want to fill in your form.
Look at other methods of engaging users. If your form is huge and scary, break it into simple manageable chunks or better yet, simplify things so much that the user only gives you data when you need it. For example, you might not need their address until you want to post something to them.
By breaking it into multiple parts you can hook them with a simple form and once they've invested that time, they'll be more likely to continue the process.
But don't harass users. If they don't want to register, pestering them with pop-ups and jaavscript dialogues will just chase them off the site completely.
With that in mind, assuming you're just trying to stop people half-filling-in forms, there are a couple of options to genuinely help people:
Detect if the form has changed and ask them a simple confirm() message.
This is all you can do. A CSS "pop-in" just won't work because you can't control* the window location in the unload event.
*You can put an event listener on all your page's links to fire off something to check the form, but this only helps if the user clicks on one of those links. It won't help if, for example, the user clicks back or closes the window. You could do both CSS and javascript but you end up with a bit of a mess.
Persist the state of the form behind the scenes.
An extension to #1. Instead of squabbling with the user, let them go where they want but save the content of the form either to session or cookie (if it'll fit) and put something on the page (like SO's orange prompt bars at the top of the page) that reminds them that they've started filling in a form and gives them a link back to the form.
When they click that link, you load the data out of the cookie (or session) back into the form and let them carry on. This has the clear benefit of letting them do what they like on your site and keeps the data safe.. ish.
If they don't come back and their cookie/session expire, that's their fault. You can only lead a horse to water. It's not your job to force it to drink.
Don't do it.
But if you want, try this. Record mouse positions and detect a quick upward thrust -- the user is reaching for the BIG X or the top left or top right. Now might be your chance for an unobtrusive box in the screen.
I've seen this implement on the web and it is evil.
If you want to trap links, you could rewrite the links in the page to go to a "you really want to leave?" javascript function, passing the destination URL as an argument.
If you wanna keep users from using their "Back" button, or keep them from putting another URL in the address bar, stop. Stop now. (1) Browsers were made to prevent exactly that kind of obnoxious behavior, and (2) Even if they allowed it, see the last two words of (1). It's freaking rude. Your site is not that special, no matter how cool you think it is.
window.onbeforeunload = function() { return "Message"; };
Use a JavaScript like this to display a leave confirmation message.
Here are just a couple of approaches I could think of but they are not without flaw:
Whatcha Gonna Do technique
Detect the mouse position going towards the edges of the browser as the user might be going to close the tab, window, go back, navigate elsewhere among other things. If so, immediately prompt them that that may be a mistake and they are going to lose out on something very valuable. However, the catch here is that you don't know for sure what their intentions were and you might piss them off with that popup. Also, they might use a bunch of shortcuts such as Ctrl+W etc to do the same.
You've Got Mail technique
If you've managed to get hold of the user's email address before they closed the page, you've hit a jackpot. As soon as the user types anything into the email box and then leaves it, immediately send it to the server using AJAX. Save the state of the page into localStorage or on the server using a cookie or something so it can be recreated later. Every couple of hours send them an email giving them a direct link to the previously saved form, and maybe with special offers this time.
History Repeats Itself technique
Then there's the infamous history manipulation where you keep stacking the current page into the document history so the back button renders effectively worthless.
Don't Put All Your Eggs In One Basket technique
Another technique off the top of my head is to create multiple windows in the background with the registration form and keep them all in sync when any the fields in any one changes. This is a classical technique and really puts the "don't put all your eggs in one basket" saying into real-life usage.
Another advantage of this awesome technique is even if the user closes one of the windows, and later comes across an identical cloned window with all the fields they filled up-to-date populated, they might get confused and think that they never closed the page. And guess what, this time they might just go ahead and fill out the registration form. But you have to be cautious with this as anything more than 2 or 3 clones will make it obvious as to what's going on.
You're Winner technique
Another technique is to tell every user they they are the Xth visitor on the site and use a good rounded number for X such as 1000, 10000, 50000, etc. Tell them that they can claim their prize once they register on the site. Imagine how special each user feels when they land on your site. The prize doesn't have to be anything tangible, it can simply be free coupons that you find on the intertubes.
Where Do You Want To Go Today? technique 1
This is basically a rip-off of your answer. Use document.location.href = 'some url' inside your onbeforeunload callback to navigate to a different page before it is unloaded.
1 Firefox only.
Note: there is no silver bullet solution here unless you write your own browser with your own security policies, but these are all optimizations that you can do to make it utterly impossible for users to leave.
Not all browsers support a modal popup, without which your page would go ahead and navigate anyway.
This is real awful requirement. The sort of requirement that is reasonable in a desktop application but entire unreasonable feature of a web site. Imagine being unable to leave a website.
The answer is either use the horrible confirm box and lump it. Or don't ask the user to enter too much data per page. Use a step by step wizard style data entry, the loss due to accidental navigation is minimised.
You can change the Value of the url using document.location.href = "www.website.com"
I can accomplish this feat using confirm boxes, but the client says that they are too ugly.
If the problem is the ugliness of the standard JS popup boxes, try something like this: http://www.sohtanaka.com/web-design/inline-modal-window-w-css-and-jquery/
Apart from that I second what most people are saying: do this with extreme caution if you don't want to lose users.
As a user experience requirement, I need to create a dynamic dashlet.
According to what I need, a dynamic dashlet would be a special dashlet that can load inside "almost every content". I say almost every content because of course this kind of dashlet would have its own limits of course. At the same time, it would be nice that the dynamic dashlet has the ability of being maximized, what in fact would show the real content (for example, an Alfresco page).
Perhaps my question is ambiguous, but the intention to give the user the chance of check execute common functionality inside that special dashlet, this way the user doesn't have to leave the dashboard improving the user experience as a consequence.
Did anybody have had such requirement or similar before? Would that be possible to do?
I would like to know some tips and suggestions in order to find out the right approach.
Thanks in advance.
You could try re-using the webview Dashlet which can also show another page.
The only problem is that not every part which is visible in Share can be accessed via url. Sure the template gets build up by regions of *.ftl's but that doesn't mean you can 'just' view the *.ftl.
The only 'dynamic' thing I see is making a custom page template which shows one or couple of regions which are dynamically build by the url.
e.g. pointing to share/page/customPage?region1=documentlibrary should insert the documentlibrary template within that page and thus it can be shown within the iFrame of the webview Dashlet.
Actually the documentlibrary is a bad example, because there is already a portletMode available for Liferay. But hopefully you'll get my point.
I am running ColdFusion MX, so I don't have the possibility of using the built-in cfimage Captcha functionality in my application, before form submitting.
But the problem is without captcha the bots submit the forms.
What will be best way to prevent automatic submitting?
Captchas don't have to be images!
Try one of the following solutions:
Most bots don't understand CSS. Create two submit buttons, the first with a value that will be rejected by the server, the second with a value that will be accepted by the server. Hide the first one using CSS.
Ask the user to answer a simple math problem. This will require you to create the math problem and store the expected solution somewhere (like the user's session), then compare the user's submitted answer with the stored answer. For extra protection, you can create simple addition, subtraction and multiplication questions. Avoid division, remainders are a pain for some users.
Bots read the names of form elements, and tend to ignore text labels. Try creating a checkbox named "optout" (like a newsletter), checked by default. Next to the checkbox, ask the user to uncheck the checkbox if they are a human. The opposite technique also works (unchecked checkbox that you ask the user to check).
All of these solutions can be done without third party code or API calls.
That being said, reCAPTCHA is pretty good and easy to integrate into almost any environment.
Take a look at cfformprotect - it will work with CFMX 6 and all later engines.
It aims to be fully accessible - and invisible to most users - with an assortment of methods to stop bots and spammers.
Also you might want to look at a CF wrapper for reCaptcha, which is compatible with CFMX 7.
A technique I used with a different technology was to use image buttons. Your POST handler gets the x,y co-ordinates where the images were clicked. I found the bots (which are just generating post requests) were passing 0,0 and by dropping those requests on the floor I brought the spam posts down to less than the real ones. Sorry that I don't know how to do that in CF but I hope the technique is useful to you.
Its always a good idea to do data validation on the server side before processing no matter which solution you use.
This post may help: http://www.bennadel.com/blog/405-Fully-Accessible-Spam-Form-Submission-Blocking-Using-ColdFusion-And-X-HTML-Version-III-.htm
How about using calculation method? Just like 8 + 5 = ?
OR
how about using ColdFusion.Ajax.submitForm?