There should be a way for the user to have some control over what gets sent off to billing. There are many ways they could have made a mistake on their hours (e.g. added hours to the wrong task, felt their effort was actually better described by a different task, another user already updated the hours for the billed effort, etc.), so the user should have tools/workflows available to them in the app that empower them to ensure their hours billed are accurate. If we agree on this first point, then deleting a ticket that has timeslot data associated to it should also be supported, but explain the impact of doing so. In the mockup above, the Delete button would be disabled until the checkbox is checked as a way to require acknowledgement before proceeding. You may decide that it works better for your use case that this action is restricted to users with elevated permissions. In that case, the delete should be disabled with a message nearby that concisely explains the situation. For example, "This ticket can only be deleted by an advanced user because it has billable hours" or similar.

Easy steps: Get familiar with the platform specific design guidelines. It will make you to know all the rules, constrains, etc. There are official guidelines for iOS, Android, Web etc. iOS: Human Interface Guidelines. Android/Web: Material Design. Web: The best one currently is Fluent Design System by Microsoft. Do best practice research. Do not open Dribbble, Behance to find inspiration if you are not familiar with the rules and constraints of the UI design. Getting to know the basic rules of the platform is the right start for all UX designers. You will be able to design a completely fine interface. It may not very nice, but aesthetics are secondary. Later you will learn that too. Then you can do a best practice research to find the right solutions and patterns for your specific problems. Unfortunately, most of the UX/UI designers are just copying designs from Dribbble without understanding the context or just understanding that what is uploaded there, 90% of it is not feasible or even may harm the business, as these are just for showing off. So only open these websites, when you are already know how to "read" and understand everything you can find there. Do not copy the aesthetics. Copy the system, how these work instead. But for this, you have to understand them.

I think you're right that the left-to-right direction of a wizard is perhaps more common. To compromise, and allow the vertical space to be expandable to accommodate a large number of steps and sub-steps, you could move your navigation buttons to be situated horizontally, below your content area. This would optimize your common case of navigating through page-by-page to mirror a typical left-to-right wizard workflow, but still would provide the screen real estate needed to show your numerous steps.

Emulate other application menus. Users want as much familiarity as possible in command menus. For commands that are unique to your application, try to see where similar commands fit into conventional categories. You can use Google Images or YouTube to look at several mainstream software examples and a spreadsheet program to map their command menu layouts. That should give you an idea on categorization and ordering. The Edit menu for three popular desktop programs:

I did not find any sources that strongly supports or is against the notion of the application's main menu containing all the commands available. But from my research, the best practice is to group commands appropriately. Meaning that it should be intuitive for the user to navigate your applications. Here are the references that I found useful: https://balsamiq.com/learn/ui-control-guidelines/menu-bars/ https://xd.adobe.com/ideas/process/information-architecture/website-navigation-design-best-practices/ https://developer.apple.com/design/human-interface-guidelines/macos/menus/menu-bar-menus/

One of the first pieces of research that designers do when thinking about design solutions is competitor analysis, which is just a fancy way of saying "checking out other designs for the same user problem". There is not always a need to reinvent the wheel, and it is even helpful to keep certain user flows or patterns consistent throughout the web as users often expect websites/apps to behave in ways that they are familiar with. Having said that, your web app and its users will have specific problems that you are trying to solve so you should design for those. It's hard to say where to draw the line between completely copying something and taking inspiration from it. Make sure you are designing for your individual web app and its users first. You can take inspiration from other apps but if everyone's reaction when they come to yours is 'oh this is X app but with a different logo at the top', it is unlikely that you have succeeded in creating an app just for your users.

Not sure if you are looking for design patterns (i.e. technology and implementation agnostic design solutions to common user tasks and problems) such as those documented in https://ui-patterns.com/ or something more specific that has CSS and HTML like CodePen or just concepts like those in Dribbble or Behance (when you search for specific keywords). I actually wish there was a site that collected good design patterns rather than the https://www.darkpatterns.org/ website that has all the bad examples. The one that I can think of which specifically relates to map based applications that has the type of detail you are looking for is https://www.mapuipatterns.com/ . But there are plenty of design systems that you can actually look up for inspirations or ideas like Atomic Design, Google Material Design, Microsoft Fluent UI, Carbon Design System by IBM, etc. Or ones specifically related to web applications like Bootstrap or Ant Design System.

I would use accordions when the user is browsing for simple and similar content which is text-heavy. A perfect example is the Frequently asked questions page. The content should be full width, nothing on its right or left.

All the information in the other answer about colors, contrast, etc. is valid from a general design perspective. But words matter a lot. In particular, users may get very confused about "this dialog". The original "Edit content" box is a dialog. But so is the popup "You have unsaved changes" box. The popup needs to be clear what "close" means (closing the original box, not the popup itself) and what is at risk. Something like: If you close the "Edit content" box, you will lose all changes that you have made. Are you sure you want to close the "Edit content" box? and then for buttons, don't use the very ambiguous "Don't close" and "Close", instead use: Continue editing content Discard content changes A little wordier on the buttons, but makes it 100% clear. This is actually quite a common problem. I have seen it with web sites and with interactions between various utilities/security systems/etc. in Windows.

What you are asking can also be categorised as "User Consent". As per GDPR, it is mandatory to take the Consent of the user to collect data and use the data for push notification. However, in-app messaging, which is considered as part of the app experience, does not actually require an opt-in from the user. Although, be careful, as not all in-app messaging is classed as user experience and would still need consent if this channel is being used purely for marketing. Here is an in-depth article https://mobilemarketingmagazine.com/consent-is-key-for-in-app-messaging-compliance-and-success that I found useful. Hope this helps you.

Creating 2 on-boarding experiences will add complexity. When I have gone though an boarding, similar to what you have described, the entire environment is in a playground (new and empty). Once the user has 'graduated' from the tutorial, they are then placed inside their production environment with the shared files present. In some cases the user can just skip the tutorial and be placed directly into the production environment. If you want to incorporate the on boarding directly into the production environment, you can have the user go through the process of performing all the operations, and then have them delete or remove those objects as a last step, while locking down the actions they can perform at each step to ensure they don't affect the production files.

I think the design you described makes sense, considering the limited context. What is important is that the user understands which objects they have selected vs which objects exist. Just be sure that if there is filtering or searching against the list, the user is still aware of the objects or number of objects selected if they are no longer shown in the search/filter. Additionally if the user needs to recall their selection, they need to be able to find what was selected in order to validate the correct selection.

When you enter an email on the "forgot password" page, there should be a message saying something like "Thanks! If there's an account associated with this email, we'll send the password reset instructions immediately." Then, your receive an email with a text explaining the you used social login. Example form Optimal Workshop: "You recently requested your password to be reset. You used your Google account to sign up to Optimal Workshop. This means you didn't need to set a password when you first signed up. To sign in to your account, all you need to do is click "Log in with Google" on the log in page. Still having trouble logging in? Contact support" Hope this solves your problem!

Try offloading the action to a single label (a text button) at the end of the statement, and have an input to select the quantity as a separate control. This way a user can select the quantity from a combo text input / dropdown (and you can use a tab index, so users can navigate into the field via the keyboard), where there's an 'ALL' selection, or user can type or select a quantity. When the quantity is 1, there's no need for the input / dropdown (it can be disabled). Pressing the ending word initiates the action. One thing i don't see in the mock you have is if there is an after state, at least a confirmation of a successful change. After modifying This is a very simple sketch, and you may have to experiment with the graphic balance so users know which control does what. That's something you can test with a prototype.

A visually hidden label is generally only used to benefit screen readers where there is something visual on the page that isn't conveyed. That is, if the design of the page implies a label is associated with an element through some visual connection but there isn't really a "programmatic" connection between the two elements, then adding a hidden label adds that "connection" for screen reader users. You would never want a case where you have a hidden label (for screen reader users) but no visible label for the sighted user. Regarding https://www.w3.org/TR/WCAG21/#label-in-name , that success criterion essentially says the visible label must match the accessible name, or at least the visible label must be contained in the accessible name. So this would be ok: print but this would not print (The accessible name is what is announced by the screen reader)

Yes of course. Backgrounds (and colors in general) are used for different purposes, including highlighting elements and whole sections. A completey different background will create a sense of alert and users will pay special attention to that. However, if all backgrounds are different, or if they follow some kind of pattern, this sense of alert ceases and users will probably ignore parts you may deem important, so be careful with that. Just in case, this is related to the https://www.usertesting.com/blog/gestalt-principles#similarity . From this link: GitHub uses the similarity principle in two ways on the page below. First, they use it to distinguish different sections. You can immediately tell that the grey section at the top serves a different purpose than the black section, which is also separate from and different than the blue section. Second, they also use the color blue to distinguish links from regular text and to communicate that all blue text shares a common function. You can also see Material Design https://material.io/design/color/applying-color-to-ui.html#sheets-and-surfaces and how to use completely different colors to stand out some content

So, I'm wondering... Is the time frame (eg 07:00-10:00) more important than the length of the session (3 hours)? I've prepared another concept of time tracking, in which the user's task is to report how long an action took, as opposed to when it was.

First, I'm going to tell you that my WebPack view and other packers is a little different from your vision. And they may have other users who will disagree with that view bridge that I will give you.Perhaps the main benefit of WebPack is the Developer. Actually at my point of view the end user of WebPack is the own must and not the user who will access the site. I'll explain why.I believe that the main advantage of packagers is to do a part of the work of developers and automate various routines... I justifi with these examples. WebPack goes prefix all your CSS styles to vc have no problem crossbrowser. He will compile your SASS, SCSS, LESS or Stylus on a standard style sheet .CSS that the browser will be able to read. It will make the includes of everything you vc want in the document, it will use something like Babel for example to treat your compatibility Java Script for old browsers. He will minify your code, remove comments etc...Then I see that the end user is Dev. and not the user who will access the platform. But logically I see pro user advantages of tb system as vc will deliver to it an optimized code, but that could have been optimized in hand, not necessarily with a Webpack of life. Until pq, in fact much of what WebPack is good practices that everyone should do, because they are the ones that will directly impact the user of the system as minify the code and prefix the properties of css, or convert images to Base64 or generate sprites, this will bring a better user experience and a better delivery performance, but this is all good practices and that with WebPack it gets easier to do.

Why do you use the upgrade method() before going to the employee's data editing screen? This step should only be directed to the editing screen and from it you submit the data to update. And in your searchFunctionId(id) you are not returning the Employee and yes null. You need to create a Function with the data coming from the database and return it.} else if (action.equalsIgnoreCase("editar")) { forward = EDITAR; Integer id = Integer.parseInt(request.getParameter("id")); Funcionario funcionario = funcionarioDAO.buscarFuncionarioId(id); /*AQUI!!!*/ funcionarioDAO.atualizarFuncionario(funcionario); request.setAttribute("funcionario", funcionario); }

Usually, large companies develop native apps. The back end of the app is the same as the site, so when you post a video on the youtube website, it also appears in the app. For what they serve https://pt.stackoverflow.com/questions/90315/o-que-%C3%A9-um-web-service/90340 . Mark Zuckerberg, https://www.theverge.com/2012/9/11/3317230/mark-zuckerberg-betting-on-html5-for-mobile-was-a-mistake-hints-at .There is no such conversion properly dictated, what some companies do is run the site within a web view in an app, Globo does this, for example. Google, on the other hand, developed a native app of youtube with the same features of the site, which of the impression that it was "generated automatically", but it was not.