What are some best practices on enabling a web application to support multiple resolutions? Specifically resolutions that are wide-screen vs. normal aspect ratio.
It doesn't seem like there is an easy answer - other than simply supporting a few fixed resolutions and using some absolute positioning to get the layout to work correctly.
This of course gets even more difficult to make it cross browser.
Does anyone have any good resources of this problem?
You can always try to use a liquid layout structure where the width of your elements are scaled proportionate to how wide their browser window is.
here is a good article explaining different layouts including liquid layout.
http://www.maxdesign.com.au/presentation/liquid/
PS. the above mentioned site (maxdesign.com.au) is using liquid layout itself, so try and change the size of your browser when reading the article.
One fast, simple, fairly robust way is to use a framework like Blueprint or 960gs to lay out the site. They're browser-independent so you don't need to worry about that, and they make most column layouts pretty easy.
They both work on the idea of creating a fixed-size container somewhere between 900 and 1000 pixels wide for your content. Most people run in at least 1024x768 nowadays. If you need more width than that for your content, you're probably doing it wrong.
The one area where ~960px might not work is mobile phones... but that's what mobile stylesheets are for, right?
In Opera and Safari (esp. their mobile versions) you can use CSS3 media queries, which let you declare completely different styles for different screen resolutions.
This can be emulated in other browsers using Javascript – Alistapart: Switchy McLayout
You can use percentages to set width and heights also, but this is also difficult sometimes.
You have two options here:
Fixed Width Layout
Flow Layout
Both have benefits and drawbacks, and in the end, it's a design decision as to which is the best choice.
Related
I have a lot of FlexLayout element in my template and it is so slow on iOS devices.
i replaced that with StackLayout and now it became little fast than before.
I'd like to know which Layout Container is fastest layout in Nativescript.
There is never one right solution for all various needs, which is why we always have options and that applies to layouts in {N} too.
Learn more about layouts interactively at nslayouts.com and choose the one that suits your use case.
If you show use what exactly you are trying to achieve, we may able to give you some suggestion. There are some general guidelines you may have to follow for better performance,
Avoid nested layouts
Use GridLayout when you need known number of partitions in your UI, the less the number of partitions are, the better the performance would be. Use FlexboxLayout otherwise.
If you just want to stack items in vertical or horizontal order, StackLayout may be a good option. Use FlexboxLayout only when you want to use flex box specific features, like when items has to be wrapped to next line, change order of items etc.,
Try to not use StackLayouts just for the shake of borders around, since you can add border to the component itself.
If you have really complicated heavy UI components, you may load it once the page has completed navigation, that may be faster.
Prefer ListView over Repeater / for loop as much as possible.
By following the above at least I can confirm, I don't hit performance issues in my apps where I have 100s of elements and 10s of partitions on screen. If you still face issues, try creating a Playground example where we can see the issue.
I noticed this same thing with FlexboxLayouts on IOS where I was doing animations with the layouts. It worked great on Android, but was very slow on IOS. I switched it to a GridLayout, and things worked a lot better.
What language or technology would I need to be able to create documents online? I want to be able to add text and images and move them into position, resize etc, similar to this.
And then when complete, create a PDF from them.
Sorry if this is a bit vague, I just need to know where to start researching.
You need to decide on your basic technology: Flash, Silverlight, Canvas, client-side SVG, server-side SVG or server-side bitmap. There are also commercial solutions that work with Adobe InDesign documents (and probably a host of other proprietary formats) but I'd expect those not to be cheap.
Flash/Silverlight require plugins, and are considered by some to be a dying technology - though I am sure that is disputed. Canvas is 'very HTML5' and is essentially a bitmap built/rendered on the client, but if you are ultimated rendering to PDF it may not provide the resolution you need. The same limitation affects building an image server-side too - you should probably be dealing with vector elements plus bitmaps, rather than rendering everything to pixels as you go.
That leaves SVG in my list, either on the client (see RaphaelJS) or on the server (see Inkscape). I'm doing some work with server-side SVG rendering at the moment, and it is promising; although subject to more scalability issues than client-side, it doesn't suffer from browser-compatibility issues or the limitations of browser rendering.
The biggest issue in browser SVG rendering is flowed paragraph text and text in/on a path - I am not sure how well these are implemented in modern browsers, or how much agreement there is between them. This is especially the case given that some of these require SVG1.2, and browsers (afaik) are only just settling on SVG1.1, after many years. But, if you just want to do standard blocks of text, bitmaps and vector elements, browser-based SVG should suit you fine.
The example you've given uses a server-side technology (SVG, or perhaps a commercial format) and renders to low-res PNG on the client.
In your case, once you've considered how to 'do the editing', you'll need to consider how to render to PDF, which will be done on the server. You could go low-level and use something like FPDF, use a report renderer like Jasper, or use a graphics system like GhostScript, Inkscape, Scribus, ps2pdf, svg2pdf etc.
Aside: I normally don't answer questions without obvious prior research. But, since you've indicated that you will indeed undertake this, I'm happy to help get you started.
I have a site that requires Trade Gothic. I'm wondering if it's better practice to use #font-face or cufon with a font that looks similar to Trade Gothic or just go the image route. Obviously, using images will look better but what is better practice? For example, is replacing header titles with images like below bad?
<h2><span>title here</span></h2>
span { display:none }
h2 { background:url(image.jpg);display:block;height:x;width:y }
It depends on the strictness of your requirement and browser support within your target audience, especially if you want to support mobile devices.
If using a similar-looking font is good enough, the requirement may really be a nice-to-have feature, so anything that degrades gracefully should work. #font-face seems the easiest to implement (just CSS and font files) and it doesn't require Flash or JavaScript (good for mobile users). Google Web Fonts is a great resource or you may even be able to create your own web font using a generator like this one.
You'll have to decide what works best for the majority of your audience and weigh in how flexible the requirement is. If you use a JavaScript-based solution and the audience has it disabled, is that a deal-breaker? Image replacement is not inherently bad, but it can be tedious to maintain if you have much content to worry about (especially if it also changes often).
I use both.
I like to use Cufon for navigation and/or main heading elements, because I think it renders better (specifically in Windows).
For any sub-headers and other text, I use #font-face, so that users may select the text.
I'm currently replacing header images with #font face, as they can load quicker, and text is always more SEO friendly, however you must be careful when doing this as this increases http requests which can then take longer to load. Also there are some legal issue as to which fonts can be used for web.
However it is especially ideal when no other font will do.
FYI browser support for #font face has been available since IE 4, as far as I know.
Well, the most obvious advantage that #font-face and cufon have against the image replacement method that you mention is that they generate your text dynamically and you don't have to create an image for each text that you want to replace.
Take a look here:
https://stackoverflow.com/questions/692990/sifr-vs-cufon-vs-typeface-js
am looking to prototype the UI for an windows application. The app will be deployed on several display devices with different (physical) screen sizes and aspect ratios. Would like to be able to generate scenarios optimized on one display and quickly check if the layout is OK on different screen sizes, orientations. That is, I'd like to prototype one set of scenarios and "automatically" generate the same scenarios on different screens. Have superficial knowledge of MS Sketchflow. Have seen some best practices at http://www.wpftutorial.net/LayoutProperties.html#best . Am wondering if folk can advise on best practices to follow in sketchflow.
Bye
To quickly be able to check how things will look, I have 2 possible suggestions:
Use the states panel to create a state group/states that change the size of the layout container (such as layoutroot) you are working with. Then in the sketchflow player, you can select the state from the navigation menu and see how it looks.
Use a ChangePropertyAction behavior from the asset panel attached to a button. You can set the height or width to the size you want. If you use 2, you can set both the height and width. This would give you the ability to control the layout size and see how it is rendered.
Hope that helps, let me know if you need more info.
Keep a consistent theme between the pages, kind of goes without saying.
See here: http://code.google.com/p/ie7-js/
Does anyone have any experience or remarks about this javascript? Is it worth including? Do you recommend it?
I know many people, myself included that are using various IE hacks to get transparent PNG support. THis looks like a little bit more help, and as long as it works, and the size is fairly small, I wouldn't see much against using it.
I've used it before, and my results are mixed. Those scripts cause IE to churn for a bit on page load. Basically, you have to think of it as iterating through Elements and stylesheet rules to apply "fixes" for areas that are deficient in that particular rendering engine. In some cases, depending on how complicated your markup or stylesheets are, that can take a bit of time and you will see the browser hang.
That said, if you can trade off that performance cost, you will save development time as you'll spend less time hacking around IE6 quirks; IE7/IE8 will provide enough missing functionality that you can avoid certain edge cases, can develop using standards better (min-width/min-height, multiple className selectors, etc.), and certain rendering issues will disappear.
However, if you just need 24-bit transparent PNG support, use a tool built for that. Including IE7/IE8.js for PNG support alone is like pounding in a nail with a tank. Use DD_belatedPNG for that.
It works, but its worth keeping in mind that ie7.js and ie8.js do much more than provide transparent PNG support. Even with the transparent PNG support, its worth keeping in mind that transparent background images cannot be tiled (repeated) using background-repeat or positioned using background-position. This hinders any ability to use CSS rollovers using background-position. I've only used it on one site I've done, and now that I'm updating the site I can't remove the ie8.js because if I do the entire website breaks layout in IE. I don't believe I'll be using it in the future, and instead rely on simple CSS hacks or simply allow my sites to "degrade gracefully" in IE6.
I know that there are some tools for fixing the transparent PNG problem which are more flexible than this. For instance, the jQuery plugin ifixpng2 will support background position, which ie7-js doesn't do.
As long as you are aware of exactly what it fixes, I would say go for it. I'm not sure about this lib exactly, but some libs get very expensive if you have a large DOM, as they tend to hook in HTC file base behaviors on EVERY DOM Element. This causes the dreaded "Loading x of y" status bar message to flash constantly on the initial load, and any newly generated DOM content.
well its beautiful and works grate way u can use cs3 features like li:hover. we did lost of project last time using ie8.js and it works great way.