In the context of the question are those conditions that prepare the ground for real execution of the code by filtering what it will do and mainly it can be done.These are conditions that the algorithm needs to ensure before performing the action that it is prepared to do.Some people know this pattern as precondition and in fact it is widely used as contracts of a function.It can be from a basic validation of an argument received to evaluate whether it is of the expected type, if it is not null, whether it is within a certain range, or if any given is in a given state, even if it is not about the arguments of the function (although this would be done in the object that was implicitly received by a method). And it can be a business rule validation how to determine if you have enough balance to accomplish that (a withdrawal for example).Examples:draw() { if (!isVisible()) return; //se não estiver visível não tem porque desenhar ... } bool saque(int valor) { if (saldo - valor + limite < 0) return false; ... } T getElement(int index) { if (index >= this.length) throw new OutOfBounds(); ... } T join(T a, T b) { if (a == null) return b; //não precisa fazer a operação se o outro não existe if (b == null) return a; ... } https://github.com/maniero/SOpt/blob/master/Java/Method/Guard.java .It doesn't have to be just a condition, and it can contain all that is necessary.Some languages have mechanisms that facilitate this, which allow to avoid certain checks, at least from their mechanism. Some have even one if in a special way that facilitates this, or that gives more semantics to this part. But that's what I always say, it's one pattern design so important that they put in the syntax.Generally she opposes putting several ifare nested or make subsequent decisions in the middle of the execution. With this pattern you tend to make it more readable by increasing the productivity of the programmer by seeing from the start if everything is ok. It is much easier to analyze the conditions necessary for use of that, which is what matters many times.And there is gain in performance the performance will tend to be better because it does not waste time with something that has no future.It's about that too: https://pt.stackoverflow.com/q/2477/101 .

No, they're totally independent mechanisms. Although technically it is possible to have a cloister mechanism in a function that is not anonymous, I only know implementations of closure in anonymous functions. But an anonymous function has no obligation to have a closure. So in theory there is no need for binding both in the two senses and in practice what happens is to be binding in one sense only.The mechanism of the clausura is only to capture a value contained in another scope for the https://pt.stackoverflow.com/q/135572/101 . So if you do not capture this value in this way in an anonymous function did not include the cloistering mechanism.Each technology can implement this as you want internally. Then it may be that a certain language causes all anonymous functions to pay the price of being able to have a clarity even without capturing a value. That doesn't mean you have a closure there, only you have the ability to have. But reinforcement that is implementation detail and it is only worth knowing for optimization issues.In fact people tend to think it's the same thing, but it's not. There are subtle differences for terms lick, https://pt.stackoverflow.com/q/227485/101 or https://pt.stackoverflow.com/q/150499/101 .Some technologies may call the same name, for example saying that a simple anonymous function is a closure, but strictly this is wrong. The language that does this usually passes an image of ignorance, or arrogance or both.An anonymous function can be implemented in a very simple way only with a pointer to provoke https://pt.stackoverflow.com/q/181032/101 and can store in some places. One closure needs a slightly more complex object to maintain the values or references for the captured variables.You can see more in: https://pt.stackoverflow.com/q/34907/101 https://pt.stackoverflow.com/q/1859/101 https://pt.stackoverflow.com/q/127121/101 https://pt.stackoverflow.com/q/344162/101 https://pt.stackoverflow.com/q/280715/101

I think this article gives a nice overview of WAI-ARIA vs. HTML5 and how to use them in practice. http://zufelt.ca/blog/are-you-confused-html5-and-wai-aria-yet The conclusion: From the above examples what can we conclude. Firstly, the primary, if not sole, purpose of WAI-ARIA is to provide information about elements in an document to assistive technology, through an accessibility API. Secondly, HTML5 on its own, without the use of WAI-ARIA is not sufficient for ensuring a fully accessible experience to users. Finally, There are situations where the line is blurred between HTML5 and WAI-ARIA, where the functionality of attributes are almost the same, but differ enough to be confusing, and to have an impact on how the two technologies must be implemented by user agents, including assistive technology.

Usually if a menu (or any interactive ui element) can never be enabled by the user it should be hidden. Otherwise, you create a hunting behavior where the user is trying to figure out how the menu could be enabled. The best approach would be to hide all menus that the user does not have access to.

You can have as many personas as you want - although, the more you have the more difficult they are to manage. The point of a persona is to represent a key user type - If you have several key user types then you need several personas. They can be segmented in any way that is relevant to the product/system you're dealing with. You can build personas by talking to users and stakeholders. Once you have your personas, you can use them to determine the needs for each user type - from that you can start building a picture of the user needs for each persona - once you have their needs you can prioritise them and see where they overlap or separate - and that's where they become useful. This slide deck has some workshop ideas for creating and developing personas (slides 5-9).

For complex interactions (e.g. CRUD) on table rows, consider an expanding row This provides the space for your interactions. For simple interactions (e.g. read-only lists), consider a modal window. I think the way Facebook lets users review all the likes on a given item is a good example of this.

From dictionary.com: Design: To prepare the preliminary sketch or the plans for (a work to be executed), especially to plan the form and structure of. Develop: To cause to grow or expand. Designers make the plans, developers execute them. The output of (UX/Software) designers is not a working system, but rather a blueprint for it. The output of software developers is a working system. By way of analogy, architects design, builders develop. UX and software designers don't build the product - developers do. Note that sometimes the design is the product, like most of the output of graphic designers. But a system needs someone to build it.

I will attempt an answer. My Background: 7+ years working as UX team of one, lead UX or team lead/manager type role for all sizes of companies. I know at some large tech companies with established UX practices and org charts i.e. Amazon, etc you're classified as either IC (individual contributor) track or M (managerial) track. If you want to change tracks , they encourage that as well. I believe it depends on how large your employer is and how defined the design team is within said employer. Examples Director of UX at 10 person startup does tasks a UX designer, sr uxd and even a jr uxd will do because company so small. Sr uxd at a 5k-30k person corporation does tasks a UX manager and UX designer will do because they're expected to "own" the project as lead designer and manage up and down with their direct boss, higher ups, jr designers even developers and PMs. Usually the manager will not do individual uxd roles because not enough bandwidth but I have seen some director/manager types pick and choose projects to be uxd on to "get their feet dirty" again.

An organisational ontology seems to define the different types of users as you specify them, and roles is one of the levels that the ontologies defined here specify: http://www.epimorphics.com/web/wiki/organization-ontology-survey In UX you may describe different types of users by doing some ethnographic research and describing them as personas, e.g. http://uxmastery.com/create-ux-personas/ but this is more of a way of capturing the essence of a user and understanding their needs rather than a classification of role.

It's difficult to visualise what you are thinking about, but here is some general advice. Onboarding The first issue you seem to describe is about 'onboarding' - getting users familiar with the functions. You don't want them to miss important things. You suggest "Show specific items in the top of the list with some color emphasize until user taps "OK, got it" or something similar, then they go to the usual feed as regular item." That can work. Sometimes websites have a banner at the top to get attention about one thing, with an 'x' to remove it once you've read it. However, it sounds like you have a few things and are envisioning users switching from one permission to another. Not sure. But if you google for "onboarding tool javascript" (without quotes), you'll come up with those great 'tour' tools that point out new features step by step. That's really the best way if there are several steps or it's a little complex. What is locked? If you just need users to know what is access controlled and what isn't, a simple red lock symbol next to the item can be all that is needed. When a user clicks/taps that, they can find a description of who that is locked to. Information structure Don't create a new menu if it doesn't make sense to the structure of the site. But if it fits under "administrator" tools, then that's the way to go. But if there are one or two extra access controlled items here and there, don't break the structure to accommodate that. Just put a lock symbol next to it. However, you could have items in both categories, too. I.e. have your "my priority stuff" - which is much like a favourites section - but also have the items in the normal spot (sorry it's hard to visualise, hope that makes sense). Of course, what you think is their priority may be different to what your users think is the priority, so what you're probably looking for is customisable favourites, with the default favourites set to what fits for that access level. The key is: what would make sense to your users? That might require testing.

Could the same person ever have both roles? Almost always, this is actually a possibility. A doctor is a patient sometimes. A seller on a website might want to buy something from the website and so on. Even if someone can't have both roles at the same time, they might change status from one to the other. And in fact, such cases may be more common than you think. You don't want to handicap yourself with a design that makes this a problem. Also, you may not be sure how your site is going to evolve and develop in the future. What if you come up with another use case that changes your understanding of who a user is and what their role is? I would lean toward having a single account that, in theory, can take on both roles. But only have one role "enabled" by default, which will drive what content the user sees and what they can do.

When describing website functionality, you can usually use "Member" to imply a logged-in user. While someone could technically be a member but not logged in, this is unlikely to be relevant to your discussions. While not logged in, they are effectively seeing the "guest" view of the site. I think this is clear: On the home page, a member will have a feed of their recent activity, while a guest will see a suggestion to sign up in the same space. A member has a button to view and edit their account details in the top navigation. etc. I don't think you need anything else. "Logged in" is implied by the context of the discussion. One place where this terminology might not apply is discussion of the log in process itself. But again, I think this will be clear from context. If there is an occasional time where it's not clear, you can always describe it with more words.

I strongly suggest that you ensure that you use more than just the photo to identify the role. The photo should really be ancillary to the informational content: the informational content can be read by eye, by screenreader, and can be machine-readable in a way that photos cannot. That deals with the informatics and accessibility issues. In terms of personalisation, users often have a single image that they use to identify themselves across many systems - you only have to look at some of the more inappropriate profile photos on LinkedIn to see that. Sourcing and managing multiple profile images is just too much work for most users. Having said that, it would be interesting to run a test to see what the uptake might be for a feature like that. I suspect it would be low but I'm willing to be proved wrong!

Is this terminology for your usage, or will the user see this as well? If this is for you, I would call the person using the app the "user", as usual. If this is for the enduser, I would refer to the user as "you" The "others" I would refer to as "contacts" or "friends".

Here is a great article from fastcodesign that I think explains it really well. Here is a an excerpt: INTERACTION DESIGNER (MOTION DESIGNER) Remember the subtle bouncing animation when you pull to refresh in the Mail app on your iPhone? That's the work of a motion designer. Unlike visual designers who usually deal with static assets, motion designers create animation inside an app. They deal with what the interface does after a user touches it. For example, they decide how a menu should slide in, what transition effects to use, and how a button should fan out. When done well, motion becomes an integral part of the interface by providing visual clues as to how to use the product. However, as with many of these 'newer' design roles, many people that work in these positions often wear a number of different hats - It can be difficult for a smaller company to justify employing someone solely for Interaction design. So you might find that a visual designer, or UI designer, or someone else is doing the role of an interaction designer and vice versa.

You could use an accordion control to allow expanding the category. However, I see a couple of problems here: If some options can be hidden, you need to handle partial selection. Otherwise, the rolled-up view would be misleading if only some of the categories were selected. Partial selection will likely be difficult to implement clearly (and it might be a technical headache, too, if it goes beyond of the capabilities of a standard UI element on your platform). The hierarchical relationship of the items isn't completely clear. For example, if I only saw the "Products" category, would I realize that "shipping settings" was a product setting? This is not necessarily intuitive. Categorizing stuff can be difficult, and there is not always an obvious organization of all the features. This is not really a problem when all options are shown, but when some information is hidden, you rely on users being able to guess what a subcategory contains. I would therefore favor not hiding the individual options. In security, clarity and precision are crucial. You need to know exactly what privileges you are giving to exactly what users. I think that makes it worth showing more information on the page, even if it gets a bit cluttered.

I'd try taking a look at the sharing options for Google Drive items and Dropbox items. Google drive allows for full sharing, view only, and view and add comments - It also allows for sharing between individuals, groups, and the general public. From memory I think Dropbox has a fairly similar system to the Google setup.

I have been challenged with kind of the same problem. To make a decision you should first of all observe the internal working/privileges of the company. I suppose a HR-manager can easily access the details of employees because it is part of his job. But than you should determine if a HR-manager can view his own details, and which details. Maybe some fields shouldn't be for his eyes. The approach of a switch between roles makes the process pretty difficult for the user (HR-manager). If you compare it to real life, can a HR-manager switch himself from normal employee to HR-manager? Not really, and why should he. His function gives him certain privileges and if the software you are developing aims to mirror the internal structure of the company these privileges should be mirrored. Maybe not the answer you'd expected, but i hopes it helps a bit

Most developers I've worked with have opinions about the UX, and often they can be valid. A lot of the time they cause more headaches than desired but that's primarily down to a lack of communication across the team. Communication is the antidote in this instance. I'll talk about some best practices and ideal scenarios that should help to illustrate some strategies for dealing with this dilemma: Good Developers A good developer will defer to the UX team when an issue arises that might affect the user - not because they are monkeys that don't know what to do, but because they respect that it's your role to investigate and solve the problem. If they have opinions on what the solution might be, they should share it but equally as a UXer you should ask them if they have any thoughts about how the problem might be solved. It doesn't mean you have to run with it, but maybe it's the best idea ever! You never know. Good Designers Likewise in good teams the UX designers will include developers in their process. Not all the time and not every day necessarily, but certainly at key points. Developers are naturally inquisitive problem solvers - if they just get lumped with answers but can't see the thinking behind them, they're bound to want to question your motivations and workings. Over the long term they'd harbour resentments if they didn't feel free to question UX. In practice One example of what I've done previously over a UX cycle investigating a particular feature (albeit a reasonably large one) would be to invite one or two devs to the initial kick off meetings and some following workshops. That way they'll get a good insight into what you're trying to achieve and why, and have a chance to provide input and feedback. This gives them a sense of ownership in the outcome, which is invaluable in maintaining team morale. After that, as the designs are evolving and feedback is being sought by the PO's etc, I'd occasionally have the devs in again to get their take on the design iterations. This isn't always ideal, but if you're skipping this part then you'd at least be advised to arrange a meeting as you hand over the project from design to dev. That way all parties can voice their concerns and remind each other of their respective roles in the process. (I hope a hand over meeting goes without saying...but you'd be amazed!) In addition: along the journey there will be various user testing sessions and feedback from parties involved and it's important to document these all somewhere that is accessible to everyone. Lots of devs I've worked with enjoy poking around the UX documentation and understanding what went on. Further reading One really great book about UX that has a section on relationships between UXers and the team at large is Under Cover User Experience Design by Cennydd Bowles and James Box http://undercoverux.com/. It's a little dated in some aspects but it's filled with great insights and timeless advice.

This is a very common pattern in enterprise apps. You have different role- or policy- driven views into a common application and model. You can either use separate layouts, or the same layout. Both can be successful. For these user interfaces, templating and widget re-use is very important, because you can assemble layouts very quickly by dropping in widgets. I would suggest modeling out the components associated with each of the tasks, and writing templates to assemble the components into a view for each role. Generally each role will have a separate template, but most of the content will be reusable. This allows you to quickly compose views that have overlapping functions (like teacher administrator). It looks like your top-level model object is a class, so a layout like this may work (widgets will be present or not depending on role):