Multiscreen designing using Fireworks?

Do you design for different devices (mobiles, smart phones, tablets, any other?) using Fireworks? What is the workflow you follow and what the current limitation in them? I am assuming that people are already using Fireworks for mobile designing when I look at examples like this one.

I can lead you into some question to understand your style or working and understand the limitations. The below first set of questions give an idea of the assets and their layout across different screen sizes.

  1. Do you design for only one screen size and then move onto a new screen size from ground zero?
  2. If you design for multiple screen, how do you reuse the assets? (Symbols?)
  3. In case you are designing for multiple screen sizes and the assets are being re-used, how do you layout the design depending on the screen sizes? (Nine slice scaling?)

The second set of questions will help me understand the resolution differences are handled during designing phase

  1. Desktop screen is generally set at 72dpi resolution whereas the device resolutions are far higher. How do you visualize the resolution differences when designing on a desktop for a tablet or mobile screen?
  2. Once the design is done, how do you see the end result? Emulate it on the desktop or host the  file and browse to it from the device?
  3. Which fonts do you generally use for multi screen designing? Does the desktop screen rendering give a font render

Once the designing is done and needs to be shown to the client, how does that happen?

  1. Do you look for some interactions which might help you win the deal?
  2. How do you currently explain the state change on gestures and other touch sensitive actions?

If you think I am going in a direction of my own, please feel free to correct me and explain how real world wireframing, prototyping, designing, interaction designing for different screen is done.

During the feedback it will be good to help me understand your workflow with the missing pieces you expect to be present to make your lives easy. Any suggestions on improvements in the existing feature set in this context is welcome.

 

 Share on Facebook

5 Responses to Multiscreen designing using Fireworks?

  1. Phil LaPier says:

    You summed up all the questions I’ve been struggling with over the past couple of weeks.
    I will not attempt to answer your questions because frankly I dont have answers. I will however share my current experience.

    I’m currently designing an Android App and using the best of my abilities to figure this stuff out. I’ve decided that for learning purposes, I will start by designing for ldpi (low dpi) deceives because we only have ldpi android devices here in the office to test on. If I can figure out the process of designing for ldpi, then I’ll figure out how to scale it for hdpi devices when ready—kind of a backwards process, I know. I’ve been using the emulator to test and tweak and therefore have no idea how the design currently holds up on ldpi devices; something I have to test before the design process gets too far along.

    I hope someone with more experience can shed light on the process. I too am struggling to figure this all out—especially designing for screen resolution variances.

  2. Aaron Beall says:

    layout…

    1.In terms of layout, yes. Well at least for broad screen classes, ie “browser” vs “mobile” vs “desktop” vs “tablet” vs “tv” — the latter two being screens I have not actually designed for, but if I had, it would have been with a fresh layout.

    2. Usually the first design dictates the design of all the others, and I manually re-use assets from that design; vectors, icons, styles, bitmap textures, text styles. I copy/paste attributes a lot. I often have a style guide in the first design with certain important design elements isolated from layout and cleaned up for re-use. I use symbols to get things like icons consistent within a single PNG, but I don’t use shared symbols across multiple PNGs. I also use symbols to preserve high resolution raster graphics so I have the freedom to resample on a different scale layout.

    3. I use 9-slice scaling a lot for things like container boxes, and I use the 9-slice tool sometimes. I also use vectors alot which make resizing fairly easy by selecting points across multiple objects and nudging them all together. What I would love is a “layout resize” tool like John Dunning’s “smart resize autoshape”, and have it be implemented persistently in a “layout symbol” — ie elements in the symbol can be given constraints for resizing.

    design phase…

    1. It’s a big problem, and long frustrated me how low dpi desktop monitors still are. I don’t have a good answer, and don’t really visualize this before hand, I just show the designs at the actual dpi they will be deployed in, which makes them look bigger on the desktop screen.

    2. I test on the device when possible. Of course a big problem with mobile is that I can’t test on every mobile device. I suppose I should use device central but haven’t really got that into my workflow yet.

    3. I try to stick to the old web standard fonts. Font rendering differences has long been a problem, I just kind of ignore it now to be honest. I design in Fireworks the way I want it, and deal with any major problems with deploying later. I flatten a lot of text, to be honest — I know that’s a sin in some people’s eyes but until I can get a consistent looking styled title text consistently across devices, I think I’ll keep indulging myself.

    shown to the client…

    1. I’ve actually used FW’s export prototype process for a long time now. It’s very basic but I wouldn’t really hope for much more, I don’t want to spend too much work on “fake” interaction when it’s just a design review, not the real thing (which would be built elsewhere.)

    2. With a storyboard of images that show a cursor/touch-point.

  3. > Do you design for only one screen size and then move onto a new screen size from ground zero?

    Yes, usually I work on a separate Fireworks document for each platform and copy/paste elements between them where necessary.

    > If you design for multiple screen, how do you reuse the assets? (Symbols?)

    Occasionally I’ll reuse symbols, swatches and styles. More often, I just copy & paste or use one document as the basis for another design. Occasionally I’ll work on designs for multiple platforms within the same document where the pages & different canvas sizes are very helpful.

    > How do you visualize the resolution differences when designing on a desktop for a tablet or mobile screen?

    Throughout the design process I export the screens and view them directly on the target device (smartphone or interactive TV). For TV interfaces I have to rescale the images horizontally before exporting because of the different pixel aspect ratio (or sometimes end up in Photoshop because it supports working at different pixel aspect ratios natively).

    > Once the design is done, how do you see the end result? Emulate it on the desktop or host the file and browse to it from the device?

    For the iPhone, I export to PDF and use the application Goodreader to preview it (sometimes using Dropbox to sync). This also works very well for simple interactive prototypes.

    For interactive TV I export JPG’s or build a simple prototype application depending on which set top box I’m targetting.

    > Which fonts do you generally use for multi screen designing? Does the desktop screen rendering give a font render

    Use fonts supported by the target device or flatten special fonts to images. I must say that Firework’s poor anti-aliasing of small type is frequently a problem. It would be helpful to see fonts rendered exactly the same as the target device/browser.

    > Do you look for some interactions which might help you win the deal?

    Yes, I often create a simple click-through prototype as described above. This is supported by documentation in the form of wireframes & flows.

    When I want to explore or demonstrate richer interactions and transitions, I use Flash.

    > How do you currently explain the state change on gestures and other touch sensitive actions?

    By annotating the wireframes. Sometimes using Luke Wroblewski’s Touch Gestures Reference: http://www.lukew.com/ff/entry.asp?1071

    I’ve also begun experimenting with Unitid’s TAP prototyping system for Fireworks and it looks promising: http://unitid.nl/2011/03/touch-application-prototypes-tap-for-iphone-and-ipad-using-adobe-fireworks/

    More about my method can be found on my blog: http://www.patrickrushton.com
    Feel free to get in touch if you have any specific questions!

  4. This is a very good question. Thanks for proposing it.

    1. Currently for mobile, we design for 2 screen sizes: Low to Mid-end mobile such as Nokia N95, and High-end iphone-type screens that use webkit, etc. High end and low end designs designs are very different, so no assets are re-used between the two. To cater for the differing sizes and ratios on the High-end mobile, we rely on good coding to make things scale. Prototype-wise, we always do landscape and portrait versions of nearly every screen.

    2. When we do re-use the symbols, or assets, such as moving between ipad and iphone, we just save out a copy of a file for one size screen resize it, and re-size the assets as need be. Assets are not always symbols, sometimes they’re just groups or whatever. Hence re-use is accomplished by “Save As”.

    3. As far as nine-slice scaling is concerned, I find that it is useful to a point. When you really need to resize someting as fiddly as a button (most of our buttons are made up of four objects: hilite line, main fill, outline, and text), it’s easier just to zoom in, and go for it with the ‘point’ selection cursor. It’s a precision job, and nine-scaling, while good, is not good enough to make very fine adjustments to size, alignment, etc.

    Second set

    1. In the days of iphone 3, we just exported png 24 files at 100%, if we want really good resolution for the iphone4, we double the pixel size to make it show it up sharp. Usually the lower size is OK for prototyping, and currently all our designs are made from a 320px wide fireworks file.

    2. Once the design is done, it is made into html files,and viewed on a mobile device. However, this is part of the development process. We constantly make html files, send them to a server and view them on the device as part of the process of designing.

    3. We use device fonts at present. Although modern mobile browsers all seem to support font downloading, our aim in mobile development is to make the download as light as possible, so we don’t send down fonts yet. You have hit a point, in the real problem with a 72 dpi screen is that it doesn’t render fonts nearly as sharp as a high res mobile screen. Maybe in the future we will have high res desktop monitors. I am eagerly awaiting a ‘retnia’ display for my Mac.

    Showing designs to the client (which is internal here) is accomplished by a very simple process of exporting out html pages with one image each. These are put on a website with a customised file browser so the users can just click and see one file at a time. This is for the visual side. If we need interactions, they are custom made in jquery, or Spry from Dreamweaver (It would be nice if it were updated!).

    Hence (point 2), the interactions are inbuilt, and the design is walked through with them in place.