I have a situation where 3 options are presented to a user by a system:
Open PDF1.
Open PDF2.
Proceed.
The system instructs the user to read the PDFs, but doesn't enforce it.
So they're free to just click the proceed button and move on to the next screen.
I drew the following diagrams, but I feel like I've got it wrong somehow.
That's not correct this way. Your 2nd attempt isn't better at all. The bars will create parallel flows, but since you join them immediately it's actually a no-op in the first case. The bar will not be reached since it waits for 3 tokens where only one can actually arrive. In the 2nd case will never continue after the join since it only gets one token from the Provides... action but need 3 to continue.
Here's a cut part of what you need to do:
There's a merge node at first to capture the tokens coming from either the action on top or from the two left ones. After there there are two decisions going guarded to the actions at the left. The can be continued to the top (guard [read next]) or to the bottom (guard [acknowledge]). That way the user can repeat reading (or skip it completely) until he passes the Acknowledge action. There's a final merge node preceding that action.
Note that the read/ack guards should appear twice for each flow to make it a machine readable model. The texts here are just overlaid but a human can understand it anyway.
I'm preparing the sequence diagram for a project. I made the following sequence diagram for a retailer updating his inventory
It's confusing to me because this is the first time I use this technique with a real project.i have used database as an object here and i don't know whether its right or wrong. And another thing i need to clarify is by using Updating i meant for both editing/add new item To the inventory. Is it wrong to do like that way? or else can we draw it separately?
The following image is part of the updating process, would any one take a look and correct me if I did any mistake.(UpdateUI- User interface).Thanks in Advance.
It does not look right. There are a couple of issues:
Your database will likely never issue any messages
Actions inside a DB are usually not exposed. You normally only call CRUD from outside for a DB.
You mix synch/asynch (likely unwillingly). Filled arrows are synch, unfilled ones as asynch.
Main Page is likely the V in MVC and UpdateUI the C. So the controller will act on a click from the user and interact with the DB.
So just from my guts here is a more reasonable sketch:
Is there any body of evidence that we could reference to help determine whether a person is using a device (smartphone/tablet) with their left hand or right hand?
My hunch is that you may be able to use accelerometer data to detect a slight tilt, perhaps only while the user is manipulating some sort of on screen input.
The answer I'm looking for would state something like, "research shows that 90% of right handed users that utilize an input mechanism tilt their phone an average of 5° while inputting data, while 90% of left handed users utilizing an input mechanism have their phone tilted an average of -5°".
Having this data, one would be able to read accelerometer data and be able to make informed decisions regarding placement of on screen items that might otherwise be in the way for left handed users or right handed users.
You can definitely do this but if it were me, I'd try a less complicated approach. First you need to recognize that not any specific approach will yield 100% accurate results - they will be guesses but hopefully highly probable ones. With that said, I'd explore the simple-to-capture data points of basic touch events. You can leverage these data points and pull x/y axis on start/end touch:
touchStart: Triggers when the user makes contact with the touch
surface and creates a touch point inside the element the event is
bound to.
touchEnd: Triggers when the user removes a touch point from the
surface.
Here's one way to do it - it could be reasoned that if a user is left handed, they will use their left thumb to scroll up/down on the page. Now, based on the way the thumb rotates, swiping up will naturally cause the arch of the swipe to move outwards. In the case of touch events, if the touchStart X is greater than touchEnd X, you could deduce they are left handed. The opposite could be true with a right handed person - for a swipe up, if the touchStart X is less than touchEnd X, you could deduce they are right handed. See here:
Here's one reference on getting started with touch events. Good luck!
http://www.javascriptkit.com/javatutors/touchevents.shtml
There are multiple approaches and papers discussing this topic. However, most of them are written between 2012-2016. After doing some research myself I came across a fairly new article that makes use of deep learning.
What sparked my interest is the fact that they do not rely on a swipe direction, speed or position but rather on the capacitive image each finger creates during a touch.
Highly recommend reading the full paper: http://huyle.de/wp-content/papercite-data/pdf/le2019investigating.pdf
Whats even better, the data set together with Python 3.6 scripts to preprocess the data as well as train and test the model described in the paper are released under the MIT license. They also provide the trained models and the software to
run the models on Android.
Git repo: https://github.com/interactionlab/CapFingerId
My question actually consists of two questions regarding the same process modelling in an activity diagram.
The process in short:
Joe uploads a file into a portal, this portal transfers the file to our server where it is checked for errors. In case of an error the server sends a message to the portal where Joe can see this (if he is still logged in or on his next visit) and upload his file again (hopefully without the errors this time). In case of success the server will also notify the portal but Joe doesn't have to take any action so we are not interested in the result. As the file is okay the system now wait for Sarah who has to start the processing of the file manually after which the process completes.
In the below diagram I have drawn this, including my two problems.
Am I allowed to let the "Notify User of succes" (I spotted the spelling mistake, thank you) in the Portal swim lane to terminate like this? If I were to put a ActivityFinal behind this that would mean the entire process would end right there which is not what we want.
Am I allowed the to join before the "process file" without a fork or do I need a fork at the very start spanning all across form Joe to Sarah?
The point of this is nothing more than an attempt to find a valid UML solution to solve this, in my own diagrams I would just do it like in the example.
Thanks in advance!
I'm not sure if it forbidden to leave an activity node without outgoing links, but for clarity (since users may think this is a mistake) I would use a flow final node (circle with x inside). This node simply terminates the flow and does not affect other flows in the diagram.
You can use a join node anywhere you want, independent if you previously did a fork or not. So what you did is correct.
I would in that case make a arrow from 'Notify user of success' to the join element, delete the arrow from the fork to the join element, and create an arrow from the fork to 'Start process'.
As far as I know the join element must have a fork at some point before it.
You can have many activity end nodes in the diagram, but I think you can't have more than one start nodes.
You have no activities on the activities diagram, do you think it is OK? No.
When a lane receives something, it should be shown as message (writing on the arrow), not as an action. Sending and receiving are special things, that are shown not as actions, but as arrow ends or if they are important as activities' parameters - border rectangles.
As for fork/join combining, it is absolutely OK.
Here is an example diagram, I have put useful for you elements on it. It doesn't mean you should copy it, only use it as a source.
Most popular web-sites that require you to log in, have the authentication form on the right side of the page. More or less. As a right-handed person, I find it rather intuitive to look at and convenient to work with—that I don't have to sprain my neck or move my mouse too much to select the username field (though of late, most pages do that by default, immediately after loading completes). Not being omniscient I wonder how a left-handed person would react to the very same UI. Which begs the question: should this not be part of the web-site design goal to flip the forms for a left-handed person? Also, I guess it matters what language you are interacting in. For a language like English that reads left to right, having the form on your right probably makes more sense.
Some examples to look at with different layout of auth forms:
Facebook, Gmail, Y! Right
Buzzword Center
SOF Left
Feel free to share your $0.02. I'd also be interested to know if actual research has gone in to this.
Update:(02/20) Some excellent posts there. Good time to summarize:
The story so far:
Most web-pages are static in terms of manoeuvrability.
Users have little/no choice on how content is served.
English being a the lingua franca of the Internet,
web sites have, over time ended up using the left-to-right
reading order of English as the order. This is in
keeping with UI design guidelines.
Being left-handed puts you at unease when using such web-sites
(not a general rule perhaps, but people have experienced issues)
Users tend to change habits rather than complain.
Clarification: Some of you seem to have misinterpreted my reference to mouse manoeuvre. It was supposed to serve as an example of what I think I'd take time to get adjusted to if things weren't the way they are. Cheers!
i'm left-handed. even more, i'm the only one i know that uses mouse on the left and swaps buttons (so the 'main' button is my index). but i don't see why you think that anything on screen should move 'for our benefit'.
one thing i've found by obsessively observing (i did my first semi-formal poll about this when i was 13 years old) other left-handed people's habits is that there's a lot more variety among us than among right-handed people. so, if you want to do some 'multi-handed' ergonomics, you shouldn't assume anything, just allow for maximum flexibility.
I don't think it has anything to do with what's natural. At least not anymore. Whatever the original reason, it's self-perpetuating now. Most websites have the login form on the right-hand side of the page. Therefore, if you're striving for the goal of "don't make me think," you should put the login form on the right-hand side of the page...
...thus increasing the number of sites that have the login form on the right-hand side of the page and the strength of the suggestion to put the login form on the right-hand side of the page so your users won't have to think...
...thus increasing... you get the idea.
I'd guess the reason for sticking it in the upper-right corner is that it's an important thing to do on a page, but not nearly as important as the title for the page/website, and that goes in the top-left corner. It's all about reading order.
I doubt right-handedness or left-handedness makes any difference. Your hand and neck use independent muscle groups.
UI Design 101 dictates that you orient the controls of your user interface (desktop application, web page, etc.) using the natural reading order of your customers. For English users, this would entail a left-to-right, top-to-bottom approach. That is, the most important information should be in the top-left corner and the least important information should be in the bottom-right corner.
The reason various websites put their login controls at different locations has less to do with conformance with some industry standard than it does with what the website designers perceive to be the most important information.
Take Gmail for example. Google is more concerned with advertising their various products (Gmail, Web History, iGoogle, etc.) to new users than they are about you logging in. Hence, they tout their products in the place that most users look first - the top-left corner. If you've already got an account, you immediately skip over this and type your login credentials on the right-hand side. And remember that once you're logged in, you never see this screen again. With this approach, Google is clearly trying to accommodate new users, not existing users. From a business perspective, this makes sense.
You might find this page interesting.
"As the owner of a website you want people to be able to use your website easily and reach content quickly - which is your ultimate goal. Being consistent with other websites in terms of the positioning of menus and content will help your visitors, give them a better overall experience and reduce the likelihood of closing the browser in annoyance. Once you have confirmed the layout, you can by all means go wild with the content and design."
Having the login box on the right side also allows you to keep the left hand navigation bar the same for people who are logged in and those who are not. See ING Direct's website for an example.
I found this article by Joel very enlightening. The part about conforming with the leaders in your field in order to eschew confusion and frustration is particularly applicable to your question.
I am left handed but I use the mouse with my right hand, always have....I feel awkward when I use it with my left now.
I'd never really thought about this before... interesting. I think it has to do with organization for an left-to-right language universe.
Since most languages move from left-to-right, it makes sense to have the site expand from the left to the right. Along those same lines, if you need to expand your menus, it makes sense to expand your menus from the left out to the right. However, user links (such as login, profile, etc.) are typically static. If you want to keep them out of the way of the rest of your navigation, better to put them on the other corner of the page - thus the right corner, rather than the left.
Edit: Sorry, I think I misinterpreted your question to mean "why are the login links on the upper right" rather than "why is the whole form on the right side of the page".
I am not expert in design, but I have my opinion about this subject.
The main reason there is alignment on the right should have to do with the way of reading. The majority of existing languages. The most people don't care about the minority of people, they only care about the majority.
Not being omniscient I wonder how a left-handed person would react to the very same UI
I don't think that this could matters for any person. But I'm not the right kind of guy to talk about this... I write with right hand :S
It would be great that all companies start to worry about this subject, for a better world :D
It's choice, not chance, that determines your destiny.
I don't see how it matters which hand you use the mouse with (FWIW, I am right-handed but use the mouse with my left hand).
Which hand you use does not alter where your cursor rests on the screen, so you don't have to move it any further with one hand than with the other. The distance is the same - i.e. however far it is from the last thing you clicked on.