User:PeterSampson/Sand-Box Front Page Images

From Audacity Development Manual
< User:PeterSampson
Revision as of 14:49, 22 July 2018 by PeterSampson (talk | contribs) (Play-at-Speed)
Jump to: navigation, search

Draft raw images for 2.1.0 front page amazing-image-map

All of these images are in png format and none are scaled. 2 and 3 have the pukka yellow border for the highlighted audio track. Any of these three look much better and clearer than the previous scaled image.

Question: Connie has conflicting requirements here. On the one hand she always prefers default images (and I bascically agree with her on this) - but she also wants images that are a maximum width of 800/810. So which has higher priority?

Personally I prefer the second image but can just about live with the third if Connie really prefers size over default - but I do find the third looks a little cramped compared to the other two. For my money this is the most important single image in the Manual by far and for me that means that we should be honoring the default layout in preference to slavishly following the size constraints imposed by old 4:3 screens - default layout easily trumps size for me and it's not exactly massively oversized it displays perfectly well without any scrolling on modern widescreens.

Full default size 902x579 pixels

This is the size and layout that you get onscreen if you re-initialize the audacity.cfg file

Front page image - full default size 902x579px.png

Intermediate size 864x587 pixels

Gale 06Feb15: I agree the layout must be default. If it's not acceptable to lose a little quality by scaling in an image editor then I will vote for this intermediate one. The scaling I have tried does give slightly dark/blocky text. Do I assume even Photoshop will have that issue? But I think this front page image should be the exception that proves the rule.

This image has reduced width by shrinking the width of the meter but still retaining the default layout - it's only slight non-default as the layout is default it's just that the meters are shrunk a little.

  • Steve 05Feb15: +1 for this version with the default layout as small as possible.
  • Bill 05Feb2015: +1 for this version.
  • Peter 06Feb15: +1 for this version.
  • Bill 05Feb2015: Imagemap ready to copy and paste.
File MenuEdit MenuView MenuTransport MenuTracks MenuGenerate MenuEffect MenuAnalyze MenuHelp MenuMenu BarPause ButtonPlay ButtonStop ButtonSkip to Start ButtonSkip to End ButtonRecord ButtonTransport ToolbarSelection ToolEnvelope ToolDraw ToolZoom ToolTime Shift ToolMultl-ToolTools ToolbarMeter Drop-Down MenuMeter Drop-Down MenuRecording MetersPlayback MetersPlayback SliderRecording SliderMixer ToolbarCut ButtonCopy ButtonPaste ButtonTrim ButtonSilence Audio ButtonUndo ButtonRedo ButtonSync-lock Tracks ButtonZoom In ButtonZoom Out ButtonZoom to Selection ButtonZoom to Fit ButtonEdit ToolbarPlay-at-Speed ToolbarHost Drop-Down MenuRecording Device Drop-Down MenuRecording Channels Drop-Down MenuPlayback Device Drop-Down MenuDevice ToolbarTimelineTrack Close ButtonTrack Drop-Down MenuTrack InfoMute ButtonSolo ButtonTrack Gain SliderTrack Pan SliderTrack Collapse buttonVertical ScaleLeft Channel of Stereo Audio TrackRight Channel of Stereo Audio TrackTrack Control PanelLabel TrackProject Rate Drop-Down MenuSnap To Drop-Down MenuSelection ToolbarStatus BarFront page image - intermediate size 864x587px.png


  • Steve 07Feb15: Does this look clear enough? The above image reduced to 800x544 and optimised with Gimp.
    • Peter 07Feb15: It does lose some of the crispness. I stand by my original statement that this is our principal key image and I think it should look it's best. The 800px reduced one just doesn't look as good imo. The full "Intermediate size 864x587" should only require horizontal scrolling on older 4:3 screens as I also pointed out earlier.
    • Steve 07Feb15: Updated with blue numbers replaced.
    • Gale 08Feb15: Steve's image is pretty darn good. The only issue I see is that if zoomed in and out in the browser, the yellow line between audio track and label track looks mostly green. It might be possible to tweak that line so it would not suffer so much in zooming, if so I would vote for it. Min-width of 1024 to accommodate the wider image is not ideal - you now have to scroll right to fully read the text on the front page. But if the min-width is not changed, the image is outside the blue background.
      • Steve 08Feb15: When zoomed in to maximum, the yellow track border is distinctly "yellow" here (Firefox on Linux). It is a 1 pixel wide line, colour #fffb99 (which is yellow). The yellow line at the top edge is #fffc99 (still distinctly "yellow"). IE may have some image scaling issues.
      • Gale 09Feb15: Actually I was using Firefox on Windows. IE zoom looks a bit cleaner if anything. The issue is that the green bordering the bottom yellow line blurs into the yellow on zoom in (or out) but that does not happen with the upper yellow line.

Audacity Main Window 800 x 544.png


This one looks much better at that lower yellow line on my monitor on Windows. I just pencilled in a 1px line at #fffc99 over the top. How about anyone else?

Audacity Main Window sharper lower yellow 800 x 544.png

Connie size 779x568 pixels

This image achieves its reduced width by moving the Play-at-Speed Toolbar and reducing the width of the meters still further. We could stretch it out a bit to the full 800 pixel width - but this size conforms to the current image width.

So it's definitely non-default - but it does conform to Connie's size - but definitely does not conform to Connie's requirement for default images

  • Bill 05Feb2015: Imagemap ready to copy and paste.
  • Peter 06Feb15: Note carefully that implementing this one would necessitate a re-ordering in the text "menu" above the image.
File MenuEdit MenuView MenuTransport MenuTracks MenuGenerate MenuEffect MenuAnalyze MenuHelp MenuMenu BarPause ButtonPlay ButtonStop ButtonSkip to Start ButtonSkip to End ButtonRecord ButtonTransport ToolbarSelection ToolEnvelope ToolDraw ToolZoom ToolTime Shift ToolMultl-ToolTools ToolbarMeter Drop-Down MenuMeter Drop-Down MenuRecording MetersPlayback MetersPlayback SliderRecording SliderMixer ToolbarCut ButtonCopy ButtonPaste ButtonTrim ButtonSilence Audio ButtonUndo ButtonRedo ButtonSync-lock Tracks ButtonZoom In ButtonZoom Out ButtonZoom to Selection ButtonZoom to Fit ButtonEdit ToolbarPlay-at-Speed ToolbarHost Drop-Down MenuRecording Device Drop-Down MenuRecording Channels Drop-Down MenuPlayback Device Drop-Down MenuDevice ToolbarTimelineTrack Close ButtonTrack Drop-Down MenuTrack InfoMute ButtonSolo ButtonTrack Gain SliderTrack Pan SliderTrack Collapse buttonVertical ScaleLeft Channel of Stereo Audio TrackRight Channel of Stereo Audio TrackTrack Control PanelLabel TrackProject Rate Drop-Down MenuSnap To Drop-Down MenuSelection ToolbarStatus BarFront page image - Connie size.png
  • Bill 05Feb2015: +1 for this version only if width is more important than showing the default toolbar layout. Moving the Play-at-Speed toolbar down one row is not a big deal for me.
  • Peter 06Feb15: -0 I'm persuaded by Steve's argument below
  • Steve 06Feb15: -1 for this version. I think it is important that the layout (order of controls) should match what the user sees. Version 2 (with lots of + votes) could be made a little smaller vertically without changing the layout. The empty track space could be reduced a little (though there should be some showing, because the user will see some empty track space), and the vertical height of the tracks could be reduced a little. I'd be +0.5 on doing that, providing those items were only reduced "a little". I'm guessing that the vertical height could be reduced by about 15 pixels without being distracting, which brings it very close to the vertical height of this third image.
  • Peter 06Feb15: The height is not the issue and does not need trimming it's well within Connie's limits - it's the width at 864 pixels that exceeds Connie's maximum requirement of 810/820. Connie aims for images to be displayed without scrolling on a 1024x768 resolution - this of course is the old-fashioned 4/3 format so why we feel the need to be constrained so that users of old screens can be accommodated without horizontal scrolling is beyond me. It's not as if scrolling is hard work. I'm pretty sure that the majority of our users are by now using wide-screen displays (I'm already on my 3rd widescreen PC) I really don't think we should always be working to the lowest common denominator. It's not as if 4:3 screen users are precluded from seeing the image - they just have to do a minimal amount of work by horizontal scrolling. I have been persuaded by Steve's argument and changed my vote to -0.