when using Requirement Management application, some ppl say, dont show your users, those areas which are not accessible for them or no permission, only show the accessible section... It doesnt sound good to me, what do you guys think?
It depends.
How much stuff do want to show? One problem many systems do have is information overload. So less options would be better.
How experienced are the users? Sometimes it might be better to have a consistent interface for many users to help novices recognize things they see at other screens.
Off the top of my head I can think of three reasons why you would want to avoid showing your users areas that they do not have access to.
You're constantly reminding them that there are features that they cannot use. This can lead to feelings of not being trusted or of not being important enough.
You waste users time. In some implementations I have seen of this the user is allowed to complete a task, for example filling out a form, and only when they submit it are they informed that they have insufficient privileges. This can lead to frustrated users.
You distract the user. Best practice is to put the bare minimum amount of information and choice in front of the user (there are exceptions to this rule). Enable your users to get their specific job done, rather than distracting them with the possibility of the option of getting all the jobs done.
If you are worried about inconsistencies in your user interface then you should probably take another look at the way you have laid your UI out and how you have segmented the tasks.
Generally speaking you should break your applications into sections of tasks (use-cases) with the permissions being tied to the particular task in the application.
For example if User A can only pull reports from a system then they should only be offered the option of going to the "pull reports" section of the application. If User B can pull reports and add orders then his screen should offer him the option of either "adding a new order", or going through to the exact same "pull reports" screen as User A. These screens shouldn't differ between the users in most cases. Their menu/navigation options would be contextual based off their permissions, and User A would never even have the option of clicking the "add new order" option.
There are obviously instances such as when certain users have a delete privilege then they are shown a delete button when other users only have the read permission. In this case your UI would differ from user to user but in an appropriate and contextual manner.
Somebody once said that an interface is done not when there is nothing left to add, but rather when there is nothing left to take away.
Related
I want to get all of my users to see announcements. As you already know, we can't force everyone to use a dashboard that would have the announcements located in it as outlined here: https://www.powerobjects.com/blog/2011/11/22/adding-announcements-to-the-dashboard-in-crm-2011/. I could add this component to the most frequently-used dashboards, but I'm not going to get complete compliance. Too many people use user-defined dashboards and views. Further, not all of our users use email or other correspondence consistently, so my channels of communication for updates to the system are limited. My best bet was to create a popup upon login containing announcements, akin to the "pending email" warning, which would appear upon login regardless of any other conditions:
I've dug around to try and see where that warning comes from, in hopes of reverse engineering it to build a new component... but I just couldn't figure it out. I've seen options on how to disable or circumvent it, which naturally is the opposite of what I'm trying to do.
Is something like this possible?
Unfortunately this is a missing most wanted piece/feature even today in latest 365 versions.
We are using Web resources in global dashboards to socialize such thing, as announcements are deprecated. We cannot circumvent personal dashboards as default scenario.
We are planning to explore Learning path for this requirement, but that’s not applicable for your version.
Just trying to find a good, simple way to block users who use adblock plus (ads are the only way writers can receive any money on our website, as with many sites).
It seems the plugins that block adblock-plus users can also be blocked.
I considered a simple solution. If their computers block ads, can't I just wrap my content in the ad, so they view all or nothing?
If not, can anyone think of any similar methods of denying users who want to deny any chance of compensation to the hardworking writers whose content they already enjoy without charge?
Possibly using a conditional statement dependent on the ad script?
It is impossible to do that.
What you can do, however, (and this is a very popular technique) is put an image behind your ad telling your viewers about how ad-blocking is bad. That way, you can possibly persuade your viewers to disable their ad-block.
If your viewer has ad-block on, they'll be able to see the image. If they don't have ad-block on, the ad will overlap the image, so they'll only see the ad.
By doing that, at least you can convince sympathetic people to perhaps disable their ad-block.
Aside from that, you're really out of luck.
Lately I've been developing applications with Meteorjs and I notice that most developers/designers don't pass the idea to the user that you don't need to refresh the browser.
In Meteor, it's completely useless to refresh the browser, the data changes are directly pushed to client.
What UI/UX Design practice match this kind of application behaviour?
I thought about adding a refresh button in the UI, in the hope that the user doesn't refresh the browser, but this is bad design, it's not an honest design. With this approach I'm lying to the user.
I've been dealing with this lately and there are a few different ways I've handled it, depending on the scenario.
Sometimes it doesn't really matter that much for UX that the user refreshes. Generally, for data that changes often, you can use methods like those described in this link about designing for realtime (provided by larsbuur's answer) to make your user understand that they don't need to refresh. The general idea is to use unobtrusive but visible and clear cues that the data has changed.
If there is not much UI state that can't be recovered from the route, refreshing the browser should work pretty much how the user expects. Generally, you don't want to try to make browser features work in unexpected ways. If you want to persist UI state across refreshes, you can try something like the Meteor package u2622:persistent-session.
You could also remind the user that they don't need to refresh after they do. For example, using the web storage API:
Meteor.startup(function() {
var reload = !!sessionStorage.getItem('reload');
var manualReload = reload && !Session.get('hotReload');
if (manualReload) {
// Tell the user they don't need to manually reload the browser
}
sessionStorage.setItem('reload', true);
Session.set('hotReload', true);
});
In certain cases, it is more important that the user understands they shouldn't refresh. For example, in online games you often have a pre-match lobby system where game settings can be adjusted, and the lobby leader is the player who has been in the lobby the longest. If the lobby leader refreshes, they will lose their position.
It is possible to make this work by having a reconnect time window where the user can reclaim their position, or the user will lose their spot in the lobby after the timeout. The mizzao:user-status is helpful with this. This is, in my opinion, the most friendly UX option, and you can even display a spinner icon next to the username to indicate to other users that the user may be reconnecting. However, my attempts at implementing this have proven to be a bit buggy and unpredictable when it comes to data integrity/server reliability.
For now, I've chosen to simply use the beforeunload event like StackOverflow does when you are typing. It's not very customizable and not as friendly as transparent reload/reconnect, but sometimes it's the best compromise when you simply want to warn the user why they might not want to refresh right now.
We should be able to access some of it so that we can edit the placement of each GUI object inside of CoreGui. So, other than security reasons, why are we not allowed to edit placement of GUI objects?
Also, why can't trusted users use CoreScripts? What if they need to access HttpGet so they can provide a nice display showing where their best friend is at the current time and place? SocialService won't always do the trick.
Can a developer (or any other experienced Roblox player, particularly one that knows the UI in and out) please answer these questions to the best of his/her ability?
I asked this in the OBC cast, specifically about editing the UI inside CoreGui. I'm not sure what security reasons could be preventing this, however. They did reply - the answer was, "Well, we definitely don't want you moving the little help icon, or the exit button."
I got the feeling the general reason is because users would become confused if everything was misplaced. For example, if you went into a website where you could play several games all made by that company (like ROBLOX), would you expect the exit or help buttons to me placed differently in every game?
They did say we will be able to change the colours.
Hope this clears things up.
Some GUI objects like the report abuse button we don't want users to have the ability to be able to remove. Another sensitive area is the chat window. If it was completely scriptable, you could write a script to make it look like another user was saying something that he wasn't. This is not really desirable.
HttpGet is currently a privileged function for two main reasons:
It would allow users to get dynamic content into levels, which would make moderation a more difficult task.
Poorly or maliciously written scripts could HttpGet roblox.com in an infinite loop, sapping our server resources.
There was no obvious benefit, but some obvious downsides. We prefer to solve only the problems that need to be solved in order to ship features, so we err on the side of caution for things like this. If we later decide to open up new functionality, like making the ROBLOX social graph available through an API, we can do that with a dedicated interface that limits the number of requests you can make to the website in a given period, and only return the info that we are sure we want you to be able to get.
It's interesting to note that for a very long time Adobe Flash player didn't support TCP sockets for the same reason.
I'm working on the quite popular website, which looks good if user has turned on "Load images" option in his browser's settings.
When you try to open the website with "turned off images" option, it becomes not usable, many components won't work, because user won't see "important" buttons(we don't use standard OS buttons).
So, we can't understand and measure negative business impact of this mistake(absent alt/title attributes).
We can't set priority for this task - because we don't know how much such users comes to our website.
Please give me some advice how this problem can be solved?
Look in the logs for how many hits you get on a page without the subsequent requests from the browser for the other images.
Of course the browser might have images cached, so look for the first time you get a hit.
You can even use IP address for this, since it's OK if you throw out good data (that is, hits that are new that you disregard). The question is just: Of the hits you know are first-time, how many don't get images?
If this is a public page (i.e. not a web application that you've logged in to), also disregard search engine bots to the greatest extent possible; they usually won't retrieve images.