Graphic Slicing Tip
-
Upload
nguyen-trong-quoc -
Category
Documents
-
view
220 -
download
0
Transcript of Graphic Slicing Tip
@2x -‐> @1x graphics All graphics for iOS are usually designed at @2x resolu/on for obvious reason. It is necessary to resize the assets to @1x using Photoshop rather than simply dump @2x graphics directly into @1x devices. This is because Photoshop’s bicubic interpola.on is much beIer than iOS’s on-‐the-‐fly nearest-‐neighbor interpola/on, especially for graphics with some textual content and/or finer details. Besides, when using na/ve @1x graphics, iOS doesn’t need to do on-‐the-‐fly resizing, hence beIer performance (at the cost of larger app filesize, no free lunch)
On-‐the-‐fly nearest-‐neighbor by iOS, hard edges & missing details
Resized by Photoshop
cropping @2x graphics When cropping @2x graphics, always produce even dimensions images. This is because coordinates in iOS is coded and/or operates at @1x resolu/on integer numbers. It is beIer to have exact match between @1x and @2x resolu/on asset to avoid auto-‐resizing by iOS, hence improve on performance. Example: aUer cropping, an @2x image is 123 x 40. If we stop here and resize to @1x resolu/on. The dilemma now is should it be 61 x 20 or 62 x 20 (integer only)? Therefore, do take one extra step and expand the Canvas Size in Photoshop to 124 x 40 in whichever direc/on that make sense. AUer that, down scale the image to @1x resolu/on. Programmer’s note: it is possible (by default) to use float/double number while coding, but it doesn’t make sense to have a 0.5 pixel. As a side effect, using non-‐integer frames on textboxes/labels causing the text to be blurry. Furthermore, using integer numbers generally gives beIer performance. This is a hard rule, should be followed all the /me. The remaining rules in this document are so: rules and need not be applied all the /me.
BuIon states Different states of a buIons (normal, pressed, selected, disabled) should have the exact same size & matching posi/on of the main graphic content. This is to avoid the graphic to ‘jump’ when pressed due to the main element in the content shiUs away from the original posi/on.
Not same size & matching posi/on
Same size but not same matching posi/on
Same size & same matching posi/on
Not same size & matching posi/on
Same size & same matching posi/on
Shadow compensa/on Adding drop-‐shadow to an element causing its overall size to increase & the center posi/on of the main graphic content to shiU. When cropping, designer should add extra padding to bring the center of the content back to its original center.
Common approach, exact crop. Easy for designer to slice, but programmer needs to add hard-‐coded margin to align the content back to center.
Designer add extra padding to align the content in the center
Extra padding added (expand Canvas Size in Photoshop)
Must be the same spacing occupied by the shadow
Margin compensa/on This is a generaliza/on of the previous Shadow Compensa/on rule.
Programmer needs to align the textbox with the top/boIom edge, hence needs to know the top/boIom margin. This requires
extra work to be done by designer to create 0reference
file.
blah blah blah blah blah blah blah blah
Programmer just need to align the textbox to the center, no extra
margin needed.
blah blah blah blah blah blah blah blah blah blah blah blah
blah blah blah blah blah blah blah blah blah blah blah blah
Uniform gradient Most mobile app plagorm should have the ability to stretch an uniform gradient image to a desired size without affec/ng quality. Therefore, it is not necessary to keep a uniform gradient at its original fullsize. Note: this is totally different from 9-‐patch technique
Ideally, the gradient should be crop down to 1px width (or 1px height in case of ver/cal gradient) for smallest filesize. However, for easy previewing in Mac’s Finder or Windows’ Explorer, 20px or so is small enough or
These examples are not a uniform gradients, hence not applicable.
9-‐patch Large, uniform and mostly rectangular graphic asset can be scaled down by a big factor by using 9-‐patch technique na/vely supported on both iOS and Android plagorms.
Android programmer’s guide: hIp://radleymarx.com/blog/simple-‐guide-‐to-‐9-‐patch/ iOS programmer’s guide: hIp://stackoverflow.com/ques/ons/2924408/iphone-‐stretchableimagewithleUcapwidth-‐only-‐makes-‐ds
Not necessary to keep such a large asset like this box
Make use of 9-‐patch graphic
support
Beside the obvious advantage in smaller asset filesize, this technique also allows stretching the UI element to any variable size, instead of having to create different and large asset for each supported sizes.
Full tutorial: hIp://www.uinnoblog.com/sms-‐bubble-‐ui-‐in-‐iphone-‐apps.html
Stretchable graphics All variable-‐size buIons can share the same graphic asset instead of using separate asset for each buIon. Note: this is just a special case of 9-‐patch technique
Android programmer’s guide: see 9-‐patch technique iOS programmer’s guide: hIp://idevrecipes.com/2010/12/08/stretchable-‐images-‐and-‐buIons/
Too long, doesn’t cater for shorter buIons
Just right, take the middle line as stretch point
Ideal, but unnecessarily short. Hard to find the right stretch line (not center).
Not necessary to keep large asset like these
Make use of stretchable graphic support
Tabbar All buIons belongs the same tabbar should have the same width & height.
Common approach, exact crop. Easy for designer to slice, but programmer needs to add hard-‐coded number for toolbar’s height. Small touch-‐able area is bad for users.
Slightly beIer. Same height as the tabbar, programmer doesn’t need to worry about ver/cally center, but need to hard-‐code for different spacing between buIons. Size of touch-‐able areas are s/ll not good enough for users.
Best approach. Same height as the toolbar, same spacing between buIon, reasonably big touch-‐able area for users.
Common approach, exact crop. Easy for designer to slice. Programmer need take care of excep/onal case.
If they appear to be the same, make them the same.
Toolbar All icons belong to a toolbar should be padded to the same height and op/onally width
Common approach, exact crop. Easy for designer to slice, but programmer needs to add hard-‐coded number for toolbar’s height. Small touch-‐able area is bad for users.
Slightly beIer. Same height as the toolbar, programmer doesn’t need to align ver/cally center, but need to hard-‐code for different spacing between buIons. Size of touch-‐able areas are s/ll not good enough for users.
Best approach. Same height as the toolbar, same spacing between buIon, reasonably big touch-‐able area for users.
Custom Tabbar / Toolbar For tabbars that really need custom posi/ons and/or sizes of individual items, the items should have at least 1 common alignment for easy placement. Usually this is the boIom edge or top edge.
Common approach, exact crop. Easy for designer to slice, difficult for programmer to posi/on each item individually. Even more
tedious without using a graphical Interface Builder
BeIer approach. To have at least 1 common alignment, boIom edge
in this case.
Best approach [if applicable]. To have more than 1 common
alignment between the items, boIom edge, top edge & height in
this case.
Pressed buIons iOS and Android system will automa/cally dims a buIon’s brightness on pressed or disabled (when a custom image is not specified). It is not necessary to create such asset unless the buIon’s color/hue/content changes on pressed/disabled.
Use auto-‐dim by the system, no need to create extra asset
Color or content changes, it’s necessary to
create extra assets
Content changes, it’s necessary to create extra
assets
Color/gradient changes, it’s necessary to create
extra assets
BuIons in a custom tabbar
Same-‐kind items A group of same-‐kind or same-‐context items should have the exact same size. This is more general than the rules for toolbar and tabbar.
Common approach, exact crop. Easy for designer to slice, difficult for
programmer to posi/on each item individually. Even harder without using a graphical Interface Builder
BeIer approach. Each individual item to have the exact same size as others.
This approach is more suitable if custom posi/ons of individual item is
required as in example below.
Best approach. Perfect grid. Designer should use Guides or Slices in Photoshop to accelerate this.
Programmer can simply write a for-‐loop to batch-‐posi/on all the items.
Smooth gradients Although capable of displaying 16 millions different colors, LCD screen in general are not capable of displaying smooth gradient between 2 very similar colors as illustrated below, on the leU. This is due to integer interpola/on between the start & end colors. Use Dither op/on in Photoshop’s Gradient tool to get rid of this ar/fact.
60,60,60
61,61,61
62,62,62
63,63,63
64,64,64
Dithering: how does it work?
Integer interpo
la.o
n
dithered non-‐dithered
Near edge graphics When a graphic is near to the edge(s) of the screen or edge(s) of another element, crop it all the way to the edge(s) to avoid having a hard-‐coded margin when placing it in the app.
Programmer needs to know the top margin above the buIon & hard-‐code it in. This also cause extra work required for designer to
create 0Reference file
Crop it all the way to the edge, no need for extra top margin. This also usually increase touch-‐able area, easier for user to touch it
If applicable, balance out top & boIom margin to bring the buIon back to the center of the graphic asset. See earlier slide on Shadow
Compensa/on
Near edge(s) When a graphic is near to the edge(s) of the screen or edge(s) of another element, crop it all the way to the edge(s) to avoid having a hard-‐coded margin when placing it in the app.
Programmer needs to know the top & leU margins & hard-‐code them in. This also cause extra work required for designer to
create 0Reference file
Crop all the way to the edges, apply Margin Compensa/on, then
apply 9-‐patch op/miza/on
9-‐patch graphic embeds all extra margins needed
Smart slicing Large graphic asset that cannot be sliced & op/mized as 1 piece using any tricks above can be broken down and op/mized using a combina/on of rules. Programmer needs to divide 1 original UI element into smaller UI elements.
Uniform gradient
Uniform gradient
9-‐patch
Sta/c elements Combine as many sta/c elements into 1 graphic asset as possible. This will reduce the number of margins, assets, fonts, etc that programmer needs to consider
Too many non-‐useful assets to be placed
Combine assets & apply Near Edge op/miza/on
Bad cropping These are simply bad, avoid at all cost. Below are samples that has shadow being cut-‐off. Most programmers & clients can’t even tell the different, but this differen/ates the average designers from the beIer ones.
Dimension reference file It is very tedious and no-‐brainer for designers to extract dimensions from a graphic file. Designers should spent more /me perfec/ng the graphics & UI designs rather than doing reference file. Applying the above rules will reduce, if not completely eliminate, the need for reference file. Moreover, non-‐stretchable graphics should always be kept to their original size and should never be stretched. Therefore, dimensions of such graphics should be obtained directly from the assets themselves & not from another reference source. However, when dimensions are really needed, the built-‐in Preview app in Mac OS or MsPaint in Windows is good enough to extract basic dimensions from a graphic screen. Programmers, please use them to measure your own dimensions as needed. BeIer tools are available, find your own preference. AUer all, the final app will be evaluated based on the provided graphic screens and not from designers’ dimension reference files.
Auto rota/on (iOS only) iOS has a built in feature to automa/cally reposi/on & resize UI elements (any UIView-‐derived class) upon device rota/on according to some defined contrainsts. Eg: align to middle; or align 10px to the top & stretch the height; or stretch the width while leaving 20px gap on each side, etc… Programmers should NOT write code to handle rota/on manually. This is because when posi/on/size of a UI element needs to be fixed/changed, this has to be changed in many places in the code. Moreover, iOS automa/cally interpolates the pos/ons/sizes from one posi/on/size to another during transi/on. It is much smoother to let the OS handle this rather than using code to create manual anima/ons.
This can be done either using code during setup phase or in Interface Builder depends on the project nature. However, note that they are opposite of each other. -‐ Using code, we specify the variable margin(s) -‐ Using IB, we specify the fixed margin(s)
Autoresizing mask in Interface Builder