I'm currently designing a web application which may be viewed by people in all kinds of resolutions 1024..1920 or even larger resolutions.
I've opted for a fixed-width design (as many other popular websites are, e.g. StackOverflow, CNN, Mint, WSJ, BofA etc.) with the lowest common denominator fitting in, meaning 1024.
Now a problem is that on some pages in my application I have to display grid-based data. I think I'm really going to anger people with large screens if I restrict them to 1024 width compacted grid data while keeping most of their screen empty.
I thought about making different style sheets and so forth for different resolutions but that will increase much of the maintenance work, graphics work etc. above of what I can manage.
Do you have any ideas how to solve this is a graceful manner (I'm just thinking maybe I have a 'creative block' here right now :) ) without having to go fully to a fluid design, which brings a bunch of problems in itself?
1) Multiple hard-coded views of the same data: Brief, Detailed, Verbose
Quick links, or tabs to allow the user to view different numbers of columns. If they need more details, they can choose the view that has more detail. They want to know, and will not be annoyed by having to scroll vertically.
2) User-Controlled columns
Allow the users to control what they see, and what columns are included in their view. You can even store and remember the views they select. The default should be the view you think most people would want to see.
3) Combination of the previous two
Allow them to choose a default, and then customize columns on a one-by-one basis. This is how MS Project works with its views, and it's very nice to work with.
Size the columns so that a reasonable number fit onto 1024, and use a horizontal scrollbar for the rest. Since your app doesn't use the extra real estate on other pages, you might decide to just stop there.
Otherwise, let the elements resize to fill the full width of the page if there is extra room (either use a table, or use min-width on the divs and 100% on the parent.
Related
I am experiencing some delay in rendering part as my page contains lots of components like (inputs and labels etc). I have placed them in panelgridlayout.
I also used audit method in jdev there also found lots of time is taken by rendering.
So, I want to know which component will be the best or suitable for this. I also implemented panelGroupLayout (with horizontal and vertical) and panelfromlayout but has same slow rendering problem.
Please help me on this.
You need to check how many layout managers you have inside of others. Too many layout managers inside one another can affect render speed.
PanelGroup Layout is for taking a "small" island of content and making its contents horiz, vertical - like buttons or fields or even groups of other islands of content - or add scroll bars if needed, like for a table.
PanelGrid layout is designed to layout a "larger" area and give the layout a grid and allow you to place items almost exactly where you want it.
Some layout managers are designed to layout "the whole page" - like PanelStretch, PanelSlider and PanelGrid, while others are for specialized tasks or group of content, like PanelGroup, FormLayout, Tab, Accordion.
So, depending on the layout, using PanelGrid may mean you do not need the others, and can simply free position all the item which may speed up rendering.
That said, there are many variables that affect rendering speed, and the complexity of the items on the ADF Faces page is not the first thing we look at - The ADF Model layer, how that is implemented and how the data source is tuned (or not) can be a bigger source of impact on rendering.
You did not specify version, that would help as well.
Before PanelGrid we tended to use PanelStretch or PanelSlider as the main window layouts that laid out the main sections of the page - and put the other ones - panel group and formlayout inside it. With the advent of PanelGrid, some of this practice is no longer needed.
This, this and this may help as well.
I'm working on a form that shows many our company's products in a FlowLayout, but on some categories that hold many products, performance in scrolling is noticeably affected. I switched to a List so I could leverage the performance benefits of using a renderer, but now I'm not happy with the layout since there's a lot of wasted space, especially if the device is in landscape mode.
My next thought was to use a Table, which I believe also uses renderers to optimize the display of its data; but to mimic a FlowLayout, I'd need to get the preferred width of some placeholder component, then divide the container's width by that to get the number of columns, and then fill the model with that number of columns in mind. I'd also need to change all that if the device changes orientation.
Before I go down that rabbit hole, I'm wondering if I'm making things unnecessarily complicated for myself and if there's already something that I can use to achieve that goal. So to summarize, what would be the most efficient way to display data (that would be shown as buttons) sequentially from left to right, and top to bottom?
I wouldn't use FlowLayout for anything serious although I doubt its the reason for your performance issues, those probably relate to something else. There is a performance how do I video which is a bit old but mostly still relevant: http://www.codenameone.com/how-do-i---improve-application-performance-or-track-down-performance-issues.html
In design terms flow layout is hugely problematic since the elements are not aligned properly thus producing a UI that doesn't look good when spanning multiple rows. I suggest using a grid layout which has a mode called auto fit. By using setAutoFit(true) on a grid of even 1x1 all the elements will take up all available space uniformly based on screen size and adapt with orientation changes.
I am envisioning a Google Glass knitting app to help my sister. Many knitters, including her, like to work from knitting charts, which are big grids with special symbols to indicate the type of stitch. You work your way down the chart, one row at a time, knitting the indicated stitches, and voila! you have a fancy sweater or whatever. She often knits while sitting on the bus, or even while walking, and having the chart on Glass would leave her hands free to do what's important.
Let me describe the ideal, but apparently unsupported, interface, and then you can tell me if there's any good substitute. Ideally, there would be a bundle containing 100 numbered rows of knitting symbols (or however long the chart is). The user sees the current row across the middle of the screen, with the rows above and below displayed more dimly. Swiping back and forward would move up and down the chart, vertically scrolling by one row and highlighting the current row. Because there are so many rows, the user needs a way to skip to a particular row, if they are picking up where they left off. I imagine them tapping to bring up a menu that allows them to speak the desired row number.
It appears that this is completely impossible at the moment. Vertical scrolling is not supported; instead, I would need to create a bundle of horizontally scrolling images of sets of three rows, with the one in the middle highlighted to be the "current" one. OK, that's an acceptable substitute. But then how does the user select a particular row? Do I need to give each card a menu allowing them to somehow request a particular row, which then gets sent over the network to the server, which then sends back a new version of the bundle with the desired row toward the beginning? That sounds wasteful, slow and fragile. Does the Glass UI provide any way to handle this kind of data? If not, is it possible that it will handle it in the future?
I can imagine plenty of applications (teleprompter, karaoke, etc.) that involve vertically scrolling through significant numbers of rows, so I'm sure I'm not the only requester of this, which makes me think that maybe, if it's not currently supported, it might be in the future. Thanks.
It sounds like you are interested in filing a feature request with the Glass team. You can do so here by clicking the New Issue button in the top left. In your request, it will be helpful to the Glass team to summarize the use case that you have described in this question.
In Blend, as soon as you insert a control (like Button) and start dragging it onto Window/Grid/whatever you get hard-coded margins and width/height.
Thus designer that I work with ends up creating beautiful static pictures that, on my side, fall apart as soon as one data-bound string is longer than the sample ones. Or if font size gets increased. Text ends up clipped or otherwise unreadable.
Blends makes it so easy to make rigid, but pretty designs, that I have a hard time selling the need for a more complex design work, using styles and panels, to my designer. By now I see only one option - let design eventually fail at customer's site and have designer learn the lesson from that failure. Of course, it is not a great solution to use customer's bad experience just to educate designer.
What are your experiences and suggestions in this area?
If it would make sense, clip long strings with '...'
Otherwise, change the sample data to be the same length as maximum allowed values.
You can even use multiple sample data sources: one for minimum lengths, one for average lengths, and one for maximum lengths. Ask the designer to check the layout using each one.
I'm designing some dialog boxes, and I'm having a hard time to fit everything. (and it has to fit on a single dialog box by design, so please don't tell me I should make two dialogs instead of one:))
I'm wondering what's the max size a dialog can have before being annoying for the end user. Of course it should't be bigger than his resolution, but are there any other boundaries to consider?
I'm trying to limit at 800x580 (so that it can display fine on a 800x600 screen without hiding the taskbar), but I expect my users to be on 1024x768 or better screen resolutions.
Is a 800x580 dialog box ok, or is it too big?
Have you considered using a tabbed layout?
Also, I believe the smallest main-stream screen resolution is 1024x600.
I'd say anything over that is too big. I try to stick below 1000x500.
I'm writing this on a netbook (ASUS) with resolution 1024 x 600. I've also noticed this is a defacto standard for most other netbooks too.
Another option: you could create a dialog that resizes itself automatically to fill the current desktop (except for the task bar).
It could also enforce a "flow" style layout for it's child controls. This would ensure the best use of the available space is made.
To get "flowing" in Windows forms you can use either the flow layout control or (for a richer interface) the WebBrowser control.
By the way, modal dialogs seem to be less popular as a way of user interaction these days. Especially large dialogs containing a lot of information/controls. This article has some good alternatives.
I think that if the user NEEDS to see all data on screen at the same time... and you can fit everything in 800x580... I think that it's a fine size.
If you know all users have bigger resolutions so don't struggle... that size is OK.
However... a way of showing lots of information and being able to edit it... could be a PropertyGrid control (an example here)... may be that could shrink a bit the form if you don't feel confortable with it being so big. Don't know if it a possibility given the needs of your client/user.
Just hope that no-one ever tries using your app on a media center running through a standard definition display. That's 640x480 for NTSC. I've suffered this problem with quite a few apps.
Whatever your pixel by pixel size, if it takes more than a few seconds for skilled users to complete the use of your window, then it shouldn’t be a dialog. Anything longer is annoying. You’d be asking your users to do too much work that is too easy to lose (e.g., by hitting Cancel accidentally) and too hard to re-entered (e.g., between sessions). If you have so many controls that the dialog needs to be 800 by anything, then it’s too many controls. 200,000 square pixels and 40 controls is the very most you should consider for a dialog. And tabs are nature’s way of saying your dialog is too complex.
Dialogs are for entering parameters to execute a single command on one or more data objects visible in the primary window for the dialog, which is why dialogs need to be small and simple. I suspect that’s not what you’re doing. Instead, you’re using a “dialog” to represent the main data objects and carry out a major task, not a single command.
What you want is a primary window, not a dialog, with all the support necessary for the complicated task you’ve set up for the user. That includes providing a means for users to save, retrieve, and copy their work. That means a menu bar and toolbar with all the standard commands, including help. The window should absolutely be modeless, and be resizable, maximizable, and minimizable.
Primary windows should be designed to work best at the size of most (over half) of your users’ screens. 1024x768 is generally fine for today’s laptop/desktop screens, not that you should use that much space if you don’t have to. If the user’s screen is smaller, or the user for any reason resizes your window below the design size, then scrollbars should appear to allow full access to all controls and content in the form –just like any primary window. The experience on the web indicates that scrolling is not a showstopper for forms.
Beyond that, tabs may be used in a primary window to increase the number of controls on it. You said you don’t want to hear about multiple windows, but multiple windows should be used instead of tabs if the user will be comparing data across tabs/windows. You can also fit more in a given primary window size by using a compact presentation (I describe this at http://www.zuschlogin.com/?p=42), but test such an approach on your users before committing to it.