[openbeos] ShowImage Bloat? [was: Re: Build Farm]
- From: Simon Taylor <simontaylor1@xxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Mon, 12 Jan 2004 20:16:37 +0000
> >Hehe interesting definition of bloat. The issue of bloat is whether
> > the
> >feature you're adding is actually useful for the core purpose of the
> >app. Whether slideshows are necessary to "Show Images" is certainly
> >questionable, IMHO.
> >
> >
> The origin of "bloat" is that software (or, if you really want to go
> to
> the original definition, anything) grows in size. I asked the
> Translation Kit team about the size and, IIRC, we were a little over
> R5
> and a little under the Dan0 file sizes. That seemed pretty reasonable
> to me.
OK then.
When I think of bloat I think in terms of features and not binary
sizes, but that might just be me :-)
> >>Believe me - there is no one
> >>who supports the "less is more" approach of BeOS than the admin
> > > team.
> >>We
> >>don't want another Windows or Linux.
> >>
> >
> >I agree "less is more". And you are using that as an argument to
> > defend
> >adding features? :-)
> >
> >
> less is more is not an absolute maxim. If it were, we would use MS-
> DOS. :-)
Yeh, good point.
> The whole crux of the issue came about that TIFF files can store
> multiple images. With that ability added to the translator (fixing
> one
> of Be's bugs), the ability to view more than one image became
> necessary
> in ShowImage. As a result, we added prev/next. Which is a good thing.
Yes.
> A slideshow is little more than prev/next with a timer. Still not too
> big
> of a deal, really.
I think viewing a slideshow is a different task than viewing an image -
I certainly know in advance if I want a slideshow or not.
I was showing someone some pictures I had in a BeOS folder and wanted
to show them as a slideshow. Instead of just "Open With"ing them with
(the yet to be created) SlideShow, I had to open one of them in
OpenShowImage, select "full screen", then select "fit to window", then
select "view as slide show". So maybe some improvents in the interface
would help the situation, but it still seems like a distinct task to
me.
> >But seriously, bloat doesn't happen overnight. The problem will be
> > in
> >the R3 timeframe, when ShowImage has features for editting images,
> >adding layers, adding text, exporting HTML image maps, etc, etc -
> > all
> >of which will have been justified by saying "it's not much more than
> >the previous version - but believe me, we don't want bloat!"
> >
> >
> We all know and fear this. Everyone has a "critical feature". From
> multi-user to an integrated IDE to networking with Macs. There is no
> "bad" feature.
Yes, that's true.
> >However, some of the things in OBOS's ShowImage are unquestionable
> >improvements - zooming images for one. However, I don't think that
> > it
> >is implemented in a very BeOS way - it would be nice if there was an
> >ArtPaint-style zoom bar in the status area to make zooming images
> > more
> >interactive. The multi-page image features may be useful for a very
> >small subset of images, but again I think the interface would be
> > better
> >in the status bar (little numbered page icons). If the image only
> > has
> >one page, then hide all of the menu for navigating multi-page
> > images.
> >
> >
> Since my BFS got corrupted (still fixing it), I haven't seen the
> newest
> iterations. If you don't like the UI, though, you should file a bug
> report on it. Posting stuff in here gets lost in the shuffle.
Yeh, OK. I need to test the latest binary myself.
> >And I think the slideshow feature is really another app. I never
> > open
> >ShowImage to view one file and then suddenly want to view a
> > slideshow.
> >I know in advance whether I want to view one or two specific images,
> > or
> >if I want to have a look at all my holiday photos. I think the
> >slideshow would be best handled by a seperate app. There is nothing
> > to
> >stop the apps working together - a slideshow button in showimage
> > that
> >launches the slideshow app with a list of all the image files in the
> >current directory, and starts the show.
> >
> So, a seperate app that contains all of the functionality of
> ShowImage
> plus SlideShow, seems less bloated to you?
Yes it does.
In the same way that a separate app that contains all the functionality
of ShowImage plus some editing functions (ArtPaint), is better than
adding all the editing functions directly to ShowImage itself.
The seperate app could have a simple UI, uncluttered with ShowImage
specific features (it would always be full screen, would always size to
fit, wouldn't need to bother with dragging cuttings about). ShowImage
itself could have a single command ("Run Slideshow"), that hands over
to the other app for all the specific settings relating only to the
Slideshow, making ShowImage a lot less cluttered too.
I think Windows does quite well at this - the "File and Picture Viewer"
or whatever it's called, allows zooming, rotating 90 degress, and
clicking a button to launch an editor (usually Paint), and another
button to launch a slideshow. That's it. Because they are seperate
apps, it's also possible to start a slideshow directly from explorer
without having to load the picture viewer for one file first.
> Honestly, someday, we will have a KeyNote/PowerPoint app, too.
> Complex
> slideshows belong in there. For now, though, a few dozen (guessing)
> lines of code that enable users to shuffle through their images
> doesn't
> seem too much overkill to me. It isn't a gut wrenching change.
But to do a "nice" slideshow app needs more thought and more slideshow-
specific UI bits that really would be bloat for the 99% of times people
run ShowImage just to look at one image.
> >Try to define ShowImage now - is it an image viewer or a slideshow
> >displayer? Now try justifying adding these useful slideshow features
> > in
> >"*ShowImage* R2":
> >* User-definable caption for each picture based on a BeOS attribute
> >
> >
> This sounds like a good idea to me, honestly. As a person who takes a
> lot of pictures, I would like a set of "standards" like People files
> for
> pictures. Date taken, people in the picture, etc. If we had such a
> standard, it would make sense to have ShowImage show those
> attributes.
> Much like BeMail/MDR uses people files.
There is already info in most digital camera images in the EXIF header.
Date and time take, exposure, flash used, thumbnail, etc.
> >* Transitions
> >
> >
> As add-ons, maybe that does make sense.
But not in ShowImage, surely?
> >* Changing the order pictures are displayed in
> >
> >
> This goes hand in hand with the above - if you can insert
> transitions,
> you have to show them. If you show them, you should be able to d&d to
> reorder them.
>
> >* Displaying files stored in different directories
> >
> >
> It will do this already, I think. If you select files from different
> places and drag them onto showimage, what happens?
The version I've got didn't do anything. Might have changed in the
latest one though.
> >I think most people would call them "bloat" for ShowImage. However,
> >given a show image with navigation consisting of "Prev Image, Next
> >Image, View Slideshow" and a seperate slideshow app specifically
> >designed for the purpose (say with a list view listing the files to
> > be
> >displayed, allowintg drag-and-drop to add files or change the
> > order),
> >it is much easier to justify new slideshow-specific features for the
> >slideshow-specific app.
> >
> >
> There is a hard line to draw, I will agree. ShowImage is about
> showing
> images. It seems to me that the better we show images, the better. We
> could certainly make a showimage that is smaller and simpler. It
> would
> even be pretty easy. In fact, some other developer might have taken a
> different direction - they might, for example, have made ShowImage
> open
> multiple instances of itself for image files with multiple images.
> Maybe
> that is better. Maybe it is not. I am not sure. There is always a
> different way with a different set of tradeoffs. In this case,
> though,
> the app didn't grow significantly, it adds to the user experience and
> is
> more useful to everyone. Certainly zooming is.
I definately agree about the zooming. That is something that is always
useful whatever image you're viewing for whatever reason.
Multi-page images is a slightly grey area (because it applies to so few
files), but it seems sensible to include it in the main app (still
viewing one image file).
Slideshow is the most out-of-place IMHO, mainly because wanting to view
a slideshow is not the same thing as wanting to view an image.
Simon
-----------------------------------------
Email provided by http://www.ntlhome.com/
Other related posts:
