My app needs to show several buttons, without overlap, and preferably without scrolling or zooming. They must be big enough to poke with a finger and read the text. Button width depends on its text length, and the height is constant. The screen size is known.
Each button represents a food about which I know some nutritional information. I'll calculate a protein:carb ratio and a fat content, both ranging from 0% to 100%.
I want to put the buttons close to a position that reflects their nutritional content: e.g. protein-rich at the top, carby at the bottom, fatty on the right and lean on the left. So cake would be bottom right and meats would be somewhere on the top edge.
Often, there'll be overlap and I'll have to nudge them away from each other.
The puzzle is to invent an algorithm for that nudging. The desiderata in order of priority are:
1) Readable and pokeable size, no overlap.
2) No scrolling or zooming required, although it'll happen when there are so many buttons that they could never fit on the screen even if we didn't care where they were.
3) Buttons should be close to where the user would look based on knowing the nutritional content of the food.
Incidentally, I'm using JS on a smartphone, not prolog or the like.
(There are some seeming dupes, but no solutions. One is about diagonal stalks, another just advocates throwing it at a game engine, but most are devoid of answers.)
Ther MArVL group at Monash University does work on constraint-based layout work. Some of their software might be applicable to your problem.
Related
I'm a CS scrub and I thought I understood everything until now. I'm being prompted to make anything I want, so I'm choosing to make a little game I've been thinking about for a few months. The problem is that I don't know where to start. We've been using JavaFX and we've done some animation but I don't fully understand everything. I don't really understand mouse events but the idea I have depends on them. Anyway, here's the idea:
The main (2D) game is about reducing fractions.
Imagine the window being split horizontally into top and bottom.
Now, imagine boxes spawning out of view and moving into view toward the horizontal center line. The boxes will only be moving vertically and each box has a random integer. When a box gets to the center, it'll stay there and allow for other boxes to land on top of it (or below it if it came from the bottom).
Boxes are eliminated by "reducing" a number in the numerator with a number in the denominator. Several boxes may be selected on one side before reducing them with the other side. Here's a picture that might help convey what I want to do:
Crude Three Frames of the Gameplay Drawn In Paint
Hopefully that all makes sense.
I've been trying to use an extension of Rectangle but I don't really know what else to do. I figure I'll need to create some ArrayLists to keep track of the boxes and some other lists to keep track of factors as well. Anyway, any help would be fantastic. Thank you guys very much!
I have a "complex" problem where I have a bunch of tooltips (orange) on top of elements (black) that can be randomly placed on screen. The tooltips are a big square with a triangle in the middle of one of it's 4 sides pointing though the element direction. By default, the triangle will be in the middle of the element, but can be moved as long as it stay close to it, so we can't easily understand it refer to this element and not another one.
The problem is, the tooltip must NOT overlap each other, and can't be out of screen.
Image of my tooltip problem
I thought about first placing every tooltips to their default position (triangle pointing down), and then check if they are out of screen or overlap another one, and if so, try another position. But using this technique (which is probably the simplest one), I do not guarantee the best placement since once a tooltip has been placed, I will not replace him if another one can't fit anywhere otherwise it become too complex.
Does someone have any tips/idea how to deal with this type of problem?
Thanks!!
This looks like an instance of the map labelling problem. Wikipedia has an article about it.
You could place all the tooltips using some sort of physical simulation of repulsive electrical charges, similar to what is done in some algorithms for drawing graphs. You could model each tooltip as an object attached with a soft spring to its black box, while simulating a strong repulsive force between all the tooltips and between a tooltip and the edge of the image. You calculate all the forces and move the tooltips iteratively, until all positions converge. You could play with making the force scale as inverse square, inverse cube, etc to find nice results.
This might be a bit of work to implement, but should probably give decent results for simple cases. It is probably impossible to guarantee that a good solution always exists, since if you add too many tooltips, your image will be full.
This question is about any code or pointer that facilitates layout of images "near" to stories within a constrained and well-defined grid.
These are the basics and inputs:
The entire object is called a newspaper. It has a set of stories (of varying text length)
Each story can either have an image associated to it, or not
The newspaper is laid out into 4 columns automatically. Text flows from top left to bottom right, down each column
Images can be placed into fixed positions - top left, top centre, top right, left centre, centre, right centre, bottom left, bottom centre, bottom right
When an image is placed, it can span between 1 to 3 columns. The height is automatically adjusted to fit the proportions, based on the span which is set.
All the actual layout work (and images flowing around the text) is done - what is required of the algorithm is the decision making only
The overall problem is to place stories in the fixed layout in an interesting way such that pictures are near to the stories associated with them, and also exhibit an interesting variation of position and span, so as to make the printed reading experience interesting and aesthetically pleasing.
This is the work required of the algorithm:
When a story with a picture is placed into the newspaper, at least
one edge of the picture must touch the story which it relates to.
We need to decide whether or not to re-order the stories so that the image density is not too biased in one area e.g. the first 4 pages have lots of pictures and the rest of the newspaper is just text.
If we choose to re-order and shuffle stories, then what is the optimal approach to resolving this placement problem?
In general, I'm not sure if this falls under the bin-packing problem - in the sense that stories can be re-ordered to minimise white-space; because we need images to be placed "near" to stories.
Any pointers to how to approach this problem, or code that facilitates a similar class of problem is appreciated.
Lets say that an ordering of stories will have those stories text appearing one after another in column order. If the story has a picture then the picture could be above/below/left/or right of the story text
Generate all possible orders of stories and pictures
Discard the order if any picture position won't fit (it can't be to the left of the leftmost column, or if placed where specified, the picture doesn't end up in one of the allowed locations).
You are left with a set of possible story/picture orders that fit the placement rules. You might then display them in miniature and have sub-editors choose the best.
Is there a standard Aqua way to handle a practically infinite document?
For example, imagine a level editor for a tile-based game. The level has no preset size (though it's technically limited by NSInteger's size); tiles can be placed anywhere on the grid. Is there a standard interface for scrolling through such a document?
I can't simply limit the scrolling to areas that already have tiles, because the user needs to be able to add tiles outside that boundary. Arbitrarily creating a level size, even if it's easily changeable by the user, doesn't seem ideal either.
Has anyone seen an application that deals with this problem?
One option is to essentially dynamically expand the area as the user scrolls through it - any time the user scrolls within X units of an edge, add another unit in that direction. Essentially, you'll never be able to scroll "all the way" to an edge, because the closer you get the farther it will expand.
If the user scrolls back away from the edge, contract it to back to no more than X units beyond where there is actually content.
Have you seen what Microsoft Excel does for this problem? It has to represent an unbounded space with scrollbars, as well.
One solution is to define a reasonable space for the original level size, and when the user scrolls to one tile away from its bounds, add another row or column of tiles, and adjust the scrollbar accordingly. This way, the user never reaches the actual bounds.
If the user decides to cut down on the level size, you could also add code that shrinks the "reasonable space" once an unused row consists only of empty tiles. This saves the user from being stuck with a huge level that they scrolled through, with no way to shrink it.
Edit: Same as Dav's answer. :)
I'm involved in writing a touchscreen application for a medical device. The program is kiosk-like, in that the start menu, etc, will not be accessible to the user, and the user will use an onscreen keyboard to type any text in the rare event that they need to. The spec'd screen size is 1280x1024.
The question is this: What's the minimum touchable button size for a reasonable interface? I'm thinking that an American dime is a reasonable minimum size in all directions, with the reasoning being that a dime is about as small as we can expect people to feel with their fingers (it's got a diameter of 17.91 mm, according to the almighty Wikipedia).
Or is a dime a bit on the large size?
EDIT: Some extra knowledge about our users. They have to have both hands, because of the nature of the device, and they will not be wearing gloves. They would have to be able to manipulate film cassettes of up to 14x17 inches in size (again, due to the nature of the device), so I feel reasonably confident that they have some manual dexterity.
There's a lot of factors that go into this that can require the buttons to be a lot larger.
Based on my experience, I would use something no smaller than a US Quarter--a dime is really too small for repeated use. If users will wear gloves or other things to "fatten" the finger, you will need even larger buttons. If you have users who are disabled or have poor motor control (more common than you would expect), a dime sized button is absolutely useless. Keep in mind that some touch screens are not particuarly accurate. I've worked with some that were up to 25 pixels off near the edges.
Also, how often are they pushing the buttons and how many buttons will be on the screen? Having to hit many small touch screen buttons in sequence will drive users crazy. That's among the reasons you'll notice that many touch screen systems such as ATM's are starting to have buttons that are in excess of 1 inch x 2 inch.
Also, how fault tolerant is the system if they accidently push the wrong button? Mabye because the screen was off or they were viewing from an angle? The less fault-tolerant it is, the bigger your buttons need to be. Mistakes happen. Smaller buttons means more mistakes.
That's going to depend a lot on the device itself as well as the UI that you're putting on it.
Many touchscreens (excluding multitouch) average the area touched, so chances are you don't want to put UI items any closer than fingertip area to cut down on mis-touches.
Touch screens need to be calibrated post installation, and even then there might be some parallax depending on the screen type or the natural angle from which the screen is being viewed.
You might also consider visual feedback on touch down and only let the event through on touch release. When you get a touch, display an x larger than a fingertip centered on the point of contact and let it track until the touch is released. That point is the click point.
Above all, user test, user test, user test.
If you're really worried about size - make it fluid so you can change it easily and test it on real users under real circumstances. Did I mention user testing?
Depends on so many factors...
All touchscreens degrade over time, and give less accurate, more noisy, and less linear results over time. Resistive touchscreens have vastly improved over time, but you'll still have issues, especially with such a large touchscreen.
Further, people have different sized fingers, and different levels of hand/eye coordination.
Lastly, the hardware and software that actually processes the touches before it even gets into your application needs to be calibrated and characterized.
So it's really much more difficult than merely asking how big the buttons need to be.
First, I'd talk to the manufacturer of the touchscreen itself, and the manufacturer of the hardware/software interface and find out their recommendations.
Second, I'd do some tests - make a few targets onscreen, and then record all the points that the touchscreen hardware sends you when you press them. Do a bunch of tests for quick jabbing presses, hard long presses, light presses, etc. See how much the input jumps around (you might be surprised...) and how fast it actually responds (heavy filtering might make the presses come late, which could reduce usability without speedy feedback).
Thirdly, I'd design the user interface for GREAT user feedback. Make the buttons wider than the finger so that when the user presses it, they still see a little of the button, and it appears to depress when the press it.
Fourthly, I'd consider adding adaptive learning. You'll have to have calibration run and rerun occasionally, but in-between you can adjust to the user slightly to decrease the likelihood of errors. It's not for the faint-hearted, though, and is easy to do wrong so take care if you want to consider it.
-Adam
I would agree somewhat with James that a US Quarter is a better target, but often you can change that so it is about a US Quarter in one dimension, and a US Dime in the other. Of course, you want to keep the center of active UI elements separated from each other by at least the distance of a US Dime, depending on how "solvable" clicking on the wrong element is. (Clicking on the wrong element in a list is easily solvable if all that is being done is selecting it; clicking on the exit button of a dialog isn't so much.)
Be sure to make your most common cases really easy to do. This usually means making a really big button; or, sometimes, making a whole UI area "clickable" (but if you do that, it's often nicer to the user to also see some sort of button in the area to imply they can click on it.)
Depending on the quality of the touchscreen, you can often "cheat" around the edges. Not only are the edges and corners easiest to hit on a traditional mouse-based interface, but they can be for touchscreen-based interfaces as well, since the user can press their finger right up against the framing element and not worry about triggering something else. Make sure your UI elements accept clicks all the way to the edge of the screen if they are near the edge, as well. Using this, you could have a US dime-sized button in each corner that would still be very repeatably clickable (although possibly lacking feedback if your users have large fingers).
Bigger is better, as we know size matters.
It is important for users of touchscreen interface to get feedback when click somewhere on screen and because this cannot be mechanical as on normal keyboard or mouse button we use sound and/or changing color.
Playing sound only when control is clicked instead of each touch anywhere in screen to achieves good usability.
If working environment is noisy you must give color feedback too, and in this case button should be twice or triple bigger than finger. It is important that user can see feedback when his hand is on screen, and you know that hands are not from glass.
Ordering on screen is important too. For mouse driven interface using of drop downs combobxes, menus and etc is good, but for touch screen you will kill usability with them. So instead of placing controls in upper left part of screen put them in bottom right side. This will give your users free of hands information area on screen when they works.
Think about left/right hand layout, and day/night color scheme too.
Currently i am working to create set of .net UI components for touch screen and you can take a look for demos soon on my web site.
Atanas