I have developed an application that must be presented on exhibition as advertising. I want it to look more sexy! What tricks do you know that enhance the appearance of your applications?
What are the best design effects the developer can use for its application? I am speaking about: glowing, shadows, maybe forms of buttons, beautiful animation of splash screens and so on.
What is YOUR favourite effect?
If you have no feeling for what looks good, then don't try magic tricks like glowing shadows or sparky gradients, it will only look like some awkward app from the late 90s. Like Chris said, effects can ruin an application as quickly as it can make one.
There is no silver bullet for good design, the best tip for someone totally lost is: Less is more. Especially when it comes to colors, avoid using many different colors.
Look on other good looking apps (Photoshop CS4, Adobe Reader 9, OSX Preview, etc etc) they are actually really clean.
If you really want to use some wpf-powers an easy trick is opacity transitions, just keep all animations short (max 0.2 seconds). And for moving animations make sure to use acceleration and deceleration, otherwise the animation will look really weird.
In terms of enhancing your app, here are some things I personally like:
Dropshadow ... Creates the effect of depth on your application, ensure a global lighting direction otherwise, it is difficult to maintain a good general effect.
Scaling ... When transitioning from one state to another, the use of scaling draws attention to the control/screen
Easing ... Whenever there is movement in the screen, the movement should be eased from start to finish.
Shine ... For rollovers, I like a subtle shine to a control, this can be achieved by moving a subtle gradient across the control.
These are just a few effects ... I think it's import to note that effects can ruin an app as quickly as it can make one, so you want to make sure that the effects you use compliment your application.
From a UX perspective, my advice is that any interaction from the user should be exaggerated. For example, rollover effects, highlighting click interactions, etc.
So in conclusion:
Use effects to highlight user interaction
Ensure that effects are used in appropriate places
Keep the effects subtle
Avoid excessive use of effects
Hope that helps!
I found the following examples:
Vista Buttons:
Innerglows:
Glass Buttons:
The only one I really use for the moment is the Bitmap DropShadow and I do not use it that much just a little shadow. The example below is too much for me. I would reduce the ShadowDepth and the opacity.
(source: microsoft.com)
But the trick is too not use them too much and to use them with consistence. Do not change your effect style over and over all around your application. Otherwise, it will be hard to take it seriously.
I prefer my effects to be subtle. Some nice, quick, smooth fade in/fade out/glow effects can add a lot of style. If you're going to do bigger animation style effects, splined animations (rather than linear) usually look a little nicer.
Don't over-do it though. If you add too much, your application is going to become frustrating to the users that just want to get the task done.
Specific effects should be taylored to match the concept of the site. Care should be taken that effects do not get in the way of use, and do not have an overkill such that they have a significant impact on performance.
Try to give your visitors something, rather than hitting them with something.
Tasteful subtle effects can often be more dramatic than glaring bursts of over activity.
A site for an attorney for instance should be clear and more bland than one for say a games site which can get quite expressive and still be acceptable.
On color:
The correct mix of color will go a long way to improve appearance with minimal negative impact on use, just use care in different shades of a color group. Try not to have a tan wording on top of a different shade of light brown background for instance, it might degrade the ability to read the text.
I would try to stay away from a mix of colors from opposite sides of the color wheel or a mix of cool and warm colors on the same page.
Personally, I would reserve the neon colors for entertainment related things or where the time you expect visitors to stay is limited.
Often when you are trying to advertise a product or service, less is more.
Related
I want to improve the performance of my game. I've done many things and there have been drastic changes in performance. I also want to change the light. but I don't know which light is more performance friendly.
It really depends on what type of lighting you are trying to do.
Baked lighting is stored in textures, so require a bit of ram, but it is fairly cheap to render, and allow for very complex light, as long as it is all static.
A single omni directional non-shadow casting light would not require any extra memory, just a fairly simple light calculation in the shader, so would be very cheap. But once you add more lights, shadows, global illumination etc, the cost goes up drastically, and you would typically need to apply various optimizations to get decent performance.This is just general recommendations that is non unity specific.
In unity you should have various settings for the lights that affect the quality of the lighting and performance. If you do not know where to start I would suggest starting with baked light, and adding realtime lights where needed, and be careful with things like realtime global illumination since that is a really difficult problem to solve.
The following picture show that my WPF lines are not as exact like a similar drawing in a non WPF application. So? Where is the problem? antialiasing? or is this a WPF feature? What am I supposed to do?
the below barchart is a simple Shape.Line.
I am not sure I would say "better line quality". Subpixel rendering is a feature in many many cases - actually in most. Financial charts are a special case - but saying WPF lines are bad in general is really an oversimplification. Especially as it points (as some have pointed out) to the usual lack of having read the documentation and learned the technology, as pixel exact rendering was reintroduced some time ago.
What you run into is the main problem that WPF is device independent and allows arbitrary zooming - so everything happens in it's own coordinate system. Which may not run down to exact a pixel. As I said - generally a feature.
Now there are edge cases (like the financial chart you point out nicely) and for that in .NET 3.0 (ages ago, seriously) pixel snapping was made available.
http://msdn.microsoft.com/en-us/library/aa970908(v=vs.85).aspx
has some explanations. It basically works by means of the SnapsToDevicePixels property.
As a matter of fact this is not the first time this question has arrived, as can be seen at - Rendering sharp lines in WPF.
There are a lot of features in WPF and it is quite mandatory to read the documentation. Especially in financial applications - which are not really static, if you deal with real time data. I suggest you do so - you can gain tremendous performance benefits by for example pre-caching parts of the UI in the graphics card memory, which is a simple other trick, easy to do.
Is there a good way to handle a large number of hotspots on a PictureBox in a WinForm? We're talking potentially hundreds. I know a couple of ways I could do this, but none of them seem to be particularly expedient. I know I can use a MouseMove event and compare the coordinates to see if the mouse is within a given rectangle, but this will likely become inefficient with more than just a few hotspots to check. I could alternatively generate lots of invisible Panels to capture the mouse events, but I'm not sure if this would ultimately be any more efficient than storing and checking against hundreds of Rectangles. I think a k-d-tree of some sort might work, but that may be seriously over-engineering this problem. I'm wondering if there's some sort of already-existing (and optimized) system in WinForms for dealing with this sort of thing?
Firstly, checking whether a point is in a rectangle is pretty quick - and the first thing I'd do is create a control and define 1000 hotspots (or what you might feel the maximum is), and then see what the performance is like.
If it is too slow, you might want to look at implementing a Quadtree. Essentially this will divide your area in to larger areas, which then have sub-areas, which then can have sub, areas, etc.
Depending on where your mouse is, you're only going to have to check a subset of the areas because you know that if the mouse is in one of the larger areas, you don't have to check the rest.
Beware, of course, of rectangles that intersect larger areas, so you might have to end up checking more of the larger areas than you need. But the QuadTree idea should get you started and will give you a performance boost.
My question is how programmers create, code, and organize subforms in general. By subforms, I mean those groups of controls that make up one UI experience. I'm looking for hints to help me better organize my form codes and to speed up the process of creating such forms. I swear to God, it takes way too long.
I've identified three broad groups of subform elements:
-Subforms have commands to do something.
-Subforms have data elements to carry out those commands.
-Subforms have states used to track things that aren't data.
The approach I use is to focus on what it takes to perform the commands which will determine which data elements are needed and how they should be validated.
Also, do programmers use check lists when creating forms?
p.s. I program as a hobby.
This is incredibly fuzzy. There is however a red flag though, you seem to be talking about UI as a starting point instead of the end result. That's a classic trap in winforms, the designer is rather good and makes it way too easy to endlessly tinker with form layouts. You forever keep adding and removing controls and event handlers as your ideas about how the program is supposed to work evolve.
This is backward and indeed a huge time sink. Effective design demands that you grab a piece of paper and focus on the structure of the program instead. The starting point is the model, the M in the MVC pattern. As you flesh out how the model should behave, it becomes obvious what kind of UI elements are necessary. And what commands should be available to the user.
The V emerges. Instead of jumping into the designer, sketch out what the view should look like. On paper. Make a rough draft of an organized way to present the data. And what operations are available to the user to alter them. Which selects the type of controls and the menus and buttons you'll need. Once that congeals, you can very quickly design the form and add the C. The event handlers that tie the UI to the model.
There's a very interesting tool available from Microsoft that helps you to avoid falling into this trap. I love the idea of it, it intentionally makes the UI design step imperfect. So you don't spend all that time pushing pixels around instead of focusing on the design of your program. It draws UI designs in a paper-and-pencil fashion, there are no straight lines. Incredibly effective not just for the programmer, also a "keep the customer focused and involved" fashion. So that the customer doesn't fall in the same trap either, nagging about a control being off by one pixel. It is called SketchFlow, link is here. It is otherwise the exact same analogue of paper and pencil, but with a 'runs on my machine' flourish.
Try CAB I'm not sure you should use it, but the pattern will help you understand how to write your gui layer in a good way.
I have a simple scene with 64 ModelUIElement3D elements, every element3d Model is a model group with 8 simple geometries, every geometry contains 3 materials, diffuse, specular and emissive.
All materials use Solid Brushes since are the fastest.
The geometries, specular material and diffuse material are Freeze to improve performance.
The only thing not freeze are the emissive materials which I’ll be updating the brush with solid brushes periodically.
When I run the application and change the brush for only one emissive material from the 1536 materials in the screen (64*8*3) the performance goes down really really bad, and the FPS go down from 60 to 15FPS.
Even I have the solid brushes in a dictionary so they are cached and created once.
This change in the brush is to make the material “blink” (really it is a fast fade-in/fade-out) in the screen. The brush change in the emissive material is every 20ms.
I see changing the brush for one material or 500 materials doesn’t make any the difference in the performance.
I comment the line where I update the brush and I get a consistent 60FPS, when I uncomment the line the FPS goes down to +/-15FPS, tried 3 different machines, 4 cores/2 Cores, very good graphic cards or medium, almost doesn't make a difference, always between 15-25 FPS.
I’m using “Performance Profiling Tool for Windows Presentation Foundation” to measure the performance, and HW IRTs per frame doesn’t go above 1 at any moment. I see when I check the checkbox “dirty-region update” that the whole scene is render every 20ms just changing the brush for one small material.
I read that WPF viewport3d doesn’t support dirty region, so I’m assuming that the whole scene is render for a minimum change.
If that is the case, is there something I can do to improve that? Since I need to create an static scene with several thousand UIElements and 10 thousands materials, but the changes are going to be so minimal so I was expecting a good performance.
If the WHOLE scene is rendered every time without chance to do anything then it is useless think on WPF to create dynamic content and I have to go for another much more complex approach as DirectX.
Please any hint how to make this work is appreciated, since I can't believe it is not possible with WPF and is some mistake on my part.
Basically I need a big scene with minimal changes, those changes happen frequently in the order of 5 to 20ms and still get the 60FPS since there are few triangles material that really change.
Thanks,
Gustavo.
I cannot give a direct solution to your question. But here's some clue:
1536 materials seems too much for the simple business charting oriented WPF 3D. It is even necessary to carefully optimize if you used low-level API like Direct3D, because down into the graphics driver architecture it will hit the batching bottle-neck, especially for DirectX 9 level driver interface.
To get best performance, the only solution is to optimize case by case with low-level graphics API, with the knowledge of graphics hardware quirks. But for a high-level general purpose 3D API, it is simply not realistic to optimize for every case. It has make some assumption, e.g. the common usage should be navigating a static scene. So that it can optimize and cache the optimized command queue to get best performance. But if the scene is changed, the cache will be invalidate and thus need to re-build and re-optimize. So it is not the size of the viewport that caused FPS drop, but the optimization.
Usually, there's hinting mechanism, by which you tell it which sub-scene-graph changes while which is static, so that to help the underlying optimization. But it is only a hint. There are many cases which make it not viable to honor the hint. And it is hard to tell the cause because the internals are encapsulated.