I would like to create kind of an 'electronic questionnaire' with about 40 questions.
Designing the form (mainly consisting of Spinner elements), I found out that in QVGA resolution, I can place a maximum of 3 questions in a layout with a text size that is still readable for elder persons.
Now of course one solution would be to use a Scrollbox, but I imagine that to be quite inconvenient (and unclear: "did I miss a field somewhere above?") and maybe even "ugly".
On the other hand, just staying with 3 questions per layout, it must look ugly on larger displays.
I just wanted to ask how others solved this design challenge and if there are maybe smarter solutions than the ones that came to my own mind so far… 8-/
Different layouts for different screen sizes and resolutions would probably be the best way to handle this. Please see this article on the Android Developers Guide for more information. Also, long forms (from a design and usability standpoint) can be kind of daunting, so from a human perspective I would recommend doing a few questions per page to prevent users from getting frustrated.
Related
I've been learning Android for the past few days and I'm getting increasingly confused about one particular topic - the design of the UI.
I'm currently using Constraint Layout, as selected by default in Android Studio.
I wonder how can I make the UI screen-size independent? Some people say guidelines (if so - where to insert them? What to do with them? What is their purpose? How is it different than just placing a button there?), some people say that good constraints are enough, some people say that I should use Relative Layout and make separate UIs for different screen sizes. I also have problems with understanding the whole concept of dp, it's kinda hard to wrap my head around it. What's the difference between using percentage values and using dp? Is dp screen-dependent?
Not to mention that I find it hard to understand the whole concept of resolution, etc.
What should I start with?
Start with a proper tutorial on android.
I would suggest to go through the Udacity basic nanodegree program. https://www.udacity.com/course/android-basics-nanodegree-by-google--nd803 Also my friend Google is your best teacher only you have to have the passion for it
I'd like some advice regarding Android UI (in)efficiency. I'm trying to determine the best way to build a particular layout for my app, however I think my initial idea potentially runs the risk of brutalising performance. Basically I have three very similar and related app components, and to configure them, I need user input. The three components share different parameters within a global set. I want to determine a nice, fluid fashion in which to display this input form on the device.
What I'd like to do is simply allow users to use one form in place of three. All three components are related/similar and they share some of the configuration parameters the user is required to enter.
My initial idea is as follows:
Build an extensive layout of UI elements necessary for initial display for any of the three instances via XML. Unfortunately, given the number of parameters organised in rows, this will amount to approximately 50 view objects in total in this case.
Create activity so that the user enters the screen, and understands
they are required to initially choose one of three values from a
Spinner widget at the top of the screen.
By using bitwise comparison operators, simply show/hide the various
controls related to the chosen Spinner value. (Triggered via
Spinner's onItemSelectedListener() )
Create some minor/lightweight animations and so on so they
understand pieces of the puzzle are being added or removed to
reflect their choice.
Alternatively, a second theory involves using three different activities, and saving state between the three, passing parameters between them... Perhaps I should abandon my initial idea and use something along those lines? A third alternative?
The primary motivation for doing this instead of just breaking it into three separate forms is it should allow for users to experience a consistent UI with minimal frustration if they choose to re-think their initial selection. Using the above, if a user fills out half of the form and decides they'd like to use an alternative option from the Spinner, their information is obviously retained, because they'd be using the same view objects.
I would like to ask you all for a little advice on how I can achieve this without risking too much of a performance decline on typical, mid-range Android devices (by that I mean handsets most users own, from Froyo up, and in particular those from Gingerbread up). I'm concerned because I only have access to one test device and it's a HTC One X handset, and that's obviously an extraordinarily poor choice for getting a handle on how capably most mortal devices can render more complex layouts.
I'd also appreciate any guidance regarding tips for optimising performance... I understand from scouring the community and Android's developer resources that rendering some layout objects is more exhaustive than rendering others, and I should opt for LinearLayout where possible (as opposed to RelativeLayout for example). Is there any definitive resource for comparing the performance of UI options? I'd very much like to spare you the time and effort, and go and acquire the knowledge myself.
Thanks in advance for the time and effort. Cheers.
Edit: I guess I should mention that if necessary, almost none of these views need to be drawn to the screen when the activity is initially loaded (the first time anyway)... If desired, I can initially load only a few views, and the Spinner widget. It'd be like loading 'No option selected' instead of Option 1, by default. The impact on the user may actually be minor if the device is sluggish because their device won't actually have to draw more than a mere handful of view objects when the activity is loaded. At any one point, the device is probably only required to render and subsequently display about 30 view objects at any one time. I guess the critical issue is, "Will the user experience a hang or a delay if their phone is struggling to load a lot of XML, even if it's not displaying it all when the activity is loaded?"
+1 for great effort on the question. My personal suggestion is that you stick with your second theory. Keep your data separate from the views -- store the entered values somewhere such as SharedPreferences or a database -- and have three different layouts (one for each form). On creating your Activity, check each common field for a previously stored value and populate that field if one exists. Trying to do something like the first list, while maybe clever, would hardly be ideal.
I think it would make more sense to just develop layouts for the different device screens. You can do this, and put different layouts in different folders. Here is a great article that talks about some of this. I wouldn't give people the "option" to choose. They may not always know the answer, so it is best to let the phone decide which layout to use.
Here is the article:
http://developer.android.com/guide/practices/screens_support.html
After trying to make sense of the Metrics and Grids page of the (fairly new) Android Design website, I gave up on a lot of things. So, basically, I'm trying to find the original layouts that are used in Android 4, so that I can apply the same concepts.
To make this question more objective and not fail under the "too broad" axe of stackoverflow, I ask you for the layout that is used to recreate, exactly and fully, the examples on that page. Did Google provide them in the samples? Maybe a well known didactic repository that strives to conform with standards?
Just as an example, it's not clear what to do to recreate the "48/3 metrics" (16/16/16) in order to make the text fit in it. What if I want to use 1-line of small text? Would it be 16/wrap_content/16, or 16/16/16 to make it consistent with other layouts around the set? What if...
I believe this would not only help the small devs, but also and most importantly, help standardize the look and feel of apps in Android Play. The site is a good start, but far from ideal.
Added details
I never asked a question with this much upvotes, and I didn't even expect that (I have other questions that I regard as "better", but by far not as many votes and favs). Not that I care about votes, of course, but that is to show that there is a great demand for what I'm asking (a bit of an ad populum here, but still...).
Replies to comments
#Ricardo Amaral:
I'm indeed sorry if I wasn't clear enough:
Mandating a standard and requesting unambiguity from it are different issues. One of the reasons I like Android is the degree of freedom we have, so I'm very much aware of the impossibility of mandating most of the common practices.
I believe it relates to the concept of "reinvent the wheel" within the concept of freedom.
Again, those were just examples. Some things are not clear... which are paddings of the outer container, and margins of the inner views? Many times that makes a difference in selectors, dragging etc. etc. etc., and that again translates into a familiar look and feel for the user. One thing feels like splitting hairs, but it quickly adds up to a lot of small differences. And the user notices it... it looks like it lacks that last "finishing touch".
#Michael Slade:
I know they're examples, that they may have been wireframed from templates. As said, I'm already reusing code from the SDK, and I know they're just examples and that we can deviate from them. Again, after all this time, nobody answered.
Optionality benefits from precision. That's what I'm trying to say and ask. Because it's a recommendation doesn't mean its guidelines can be whatever you want them to be. If you do that, it's not the recommendation anymore. That's the whole point of recommendations, by the way: provide an implementarion theory without forcing anyone.
Thanks everyone!
Hate to break it to you but it's likely that the images on the page you like were created with a drawing program, and there are no example to go with them.
Without someone actually going to the effort to create samples for you, your best bet is to go through the samples that come with the android SDK - they will follow the guidelines in most cases.
And remember, they are just guidelines. At the end of the day it's up to you to create a pleasant and smooth user experience, however you see fit.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I've been "Googling" for a while now but I am coming up empty on any decent tutorials on how to "prettify"my android app.
Currently, my android app is fully functional but all it is is a bunch of buttons,text on several views.
What options or techniques exist to make it look beautiful, other than changing the font type, size or colour. Also changing the background colour or image isn't exactly a job done.
I appreciate any guidance on this!
Update
I am not looking for a designer. I just want know how else is someone supposed to design beautiful android apps - surely its just not the XML? Is it just about making a great background and fitting everything around that?
I know the pain you're going through - I'm still coding my app but I'm also on my third design iteration. UI design is definitely out of my comfort zone but then again, it's good to push yourself into other areas, now and again, if only to appreciate the skills which the pros have. That said, check out the new Android UI patterns here and you should definitely consider things like a colour scheme, fonts and overall look-and-feel. There's another good article here by Reto Meier about his approach. Good luck.
Although it is sacrilege of the highest degree, you could sneak a peek (sic) at the UI guidelines for iPhone.
In general, there are two approaches to making a good looking UI.
The first approach is to specialise. Pick a particular resolution, set your font sizes in stone, use precisely positioned images for rounded corners etc.
The second approach is to generalise. Make sure that your layout looks 'okay' on most of the screen sizes. Make sure it still looks good when the user changes the font sizes (etc). Try to keep the graphical elements away from the text elements (e.g. you might put a graphical border around the edges of your app - whereas the specialist would have a graphic filling the whole background with 'holes' for the text to go in)
Thirdly ( generalisations are made to be broken :D ) you can make your app skinnable. It is hard for one person to come up with a design that everyone likes. But if you allow the user control over the ui elements (especially colours and contrasts) they can personalise it and achieve something that is better for them than anything you could come up with. Everyone else on the planet might hate the colour scheme they pick, but they feel that it is perfect.
Fourthly ( sorry ) you can try customising the controls. On the iPhone (for instance) the built in buttons that come with the API are incredibly ugly on anything other than a white or light grey background (their shadow is wrong) - but you have no control over the appearance of the button! You can't even change its colour. So in order to have buttons that don't suck, you pretty much have to roll your own custom control. I highly recommend looking at the Donut Games iPhone apps - they have a 'big round bouncy button' that they re-use a lot.
Don't clutter your app.
Make sure your controls are a fair distance apart. Find someone with 'fat fingers' to user test it for you (use a frozen sausage if you don't have any friends).
Keep in mind that a touch UI is fundamentally different from a mouse and keyboard UI. For starters the tip of a mouse is 1x1, the tip of a finger (according to Apple HIG (and again, apologies for mentioning Apple)) is 40x40 on the old (non-retina) displays. Presumably it is 80x80 on the new one. That means a finger is somewhere between 1600 and 6400 times less accurate than a mouse. One implication of this is that no control should be smaller than 40x40. If you were making a boardgame for instance, that would imply that (on older iPhones) that a chessboard is about the smallest your squares/hexes should get (8 across at 40 pixels is 320 pixels, the same as the phone width).
You can see this effect (a control being too small) with the default Apple info button (the i in a white circle) - it is something like 18x17 pixels, and sometimes can be quite hard to hit (sometimes you get it first go, it creates an inconsistent feel to the app). Cunning developers stick a 40x40 invisible 'panel' behind the button and delegate the clicks that go through to that back to the button.
Don't use small controls!
I don't know if this helps you as much as it helped me but I really got a lot out of this Google IO 2010 Video on UI-Design-Patterns:
http://www.google.com/events/io/2010/sessions/android-ui-design-patterns.html
If you don't have an hour to spend, just read over the slides of the presentation:
http://dl.google.com/googleio/2010/android-android-ui-design-patterns.pdf
I would definitely recommend to watch the video session though!!!
Good luck and have fun!
From experience, a good Software Engineer is not necessarily a good UI Designer. They require two different skill sets, I recomend subcontracting the design to a good UI designer. Even if all they do is a mock up and then you go back and implement their design idea.
One cannot learn desing because it is an art. For this one has to believe in onself and let it happen. There is nothing more important for desing than a positive attitude and of course, in this case, some good Photoshop and Fireworks skills...
But essentially it is an ability to visualise that matters and this is why so many games on android market just don't look good, for rare are people who are good programmers and graphics artists at the same time... yet everything can be achieved given proper attention.
Basically, my answer is: if you want to do it yourself, then you must forget that you are a programmer and believe that you are an artist, desinger and producer. Only then, from that new perspective, you can create what is needed for your product.
I've seen that some Android devs promote this form of declarative layout:
<TextView style="#style/my_textview_style" />
i.e. that pretty much all the attributes (including the ID) go into the style definition. It certainly makes for shorter layout files, but is it a step too far?
What would you recommend goes in the style definition, and what should stay in the layout, and why?
I've started doing Android dev this year, but have prior experience of development. Issues like this are so important, the "way" we use the tools, the habits, to be more efficient. I appreciate you sharing your views on what works for you, for clarity, for efficiency, for maintainability, for app reliability.
I've pondered this very question and it becomes much more pertinent when dealing with multiple device sizes and densities.
Putting too much information into the styles can limit their use, especially when dealing with landscape and portrait layouts. For example a landscape layout may in fact be wholly different in composition but require very similar styles.
In these cases it helps to use the . notation to ammend style differences, for example.
<MyPage>
<MyPage.portrait>
<MyPage.landscape>
See below for information on the above approach to creating styles.
http://developer.android.com/guide/topics/ui/themes.html
MyPage defines the common properties for your layout and you then override these values in the portrait and landscape extensions.
I..e you might have more right and left padding in landscape than portrait.
The problem i've found is that the themes and styles xml files get huge, especially if like me you have many activities, and if you address lots of creative changes then you can end up with lots of messed up definitions.
At this point you have to take stock, tidy up and re-factor.
My only advice is that you plan really well upfront. Define a naming system that accommodates your project, write it down and stick to it.
Possible style naming convention
<section>_<componentName>_<componentType>_<orientation>
home_leftPanel_btn_horizontal
home_leftPanel_listview
home_leftPanel_listview_horizontal
A similar approach to themes should be adopted.
I'm still working this out, so can't give fuller examples.
Pushing those things out into the style is a good practice if you plan on skinning your application differently. If you plan on releasing two versions with just a different look then by all means push those into a style. As you say it cleans up your layout files quite a bit.
Should you push IDs into styles. No because IDs are the hooks by which you're code will grab references to those objects. I can't see much of a point to always having your program externalize IDs. So I'd say that practice is going too far.
Now should you do this every time? Well I think that really depends on if you think you need the benefit this brings to reskin the application. Some people can't say no to a good idea, and try and do every good idea all the time. While that's admirable it's not productive. Experience is knowing what good ideas you need and what good ideas are just fluff for this application your are working on right now. To keep ourselves productive we need only the good ideas that make us move faster, and all other ideas are just art. How do I choose? Refactor, refactor, refactor. Do it fast, then refactor to clean it up based on the next requirements I'm working on. Do it fast, then refactor. Repeat until my boss smiles.