software-store-developers team mailing list archive

[Matthew McGowan <matthew.joseph.mcgowan@xxxxxxxxx>]

Hey all,

Disclaimer: I have not read the replies, apologies if i cover existing
territory.

Are the changes proposed arbitrary or are they based on user testing
evidence or other?  This is not clear and i think the reasons need to be
made more explicit.  It's a lot of effort to rearrange the UI and we should
be as clinical as possible...

I really think we should make explicit UI issues users are having and work
from there.  Currently what issues do the mockups deal with in a
satisfactory manner?  The UI is subjective territory but nevertheless we
should work from some evidence and issues.

For instance why is so much importance being placed on Version, License and
Total Size?  The position proposed in  p59-small creates a large amount of
empty space in the left hand margin and for what gained value?  How much
does the average user gain from knowing these particulars?  Of these
details, in my personal usage all i really would be interested in is the
download size, and only then if i was on a restricted/slow internet
connection. On a high bandwidth connection, however, i would only care about
this stuff when i actually selected a package to intsall, and even in this
scenario it's merely academic.

On the otherhand we are suggesting truncating the app description
initially... not sure this is wise but this is based on my gut instinct
only. Is there evidence to suggest this is best?  The user can have the app
description, the only truely comprehensible information about the app,
available in full before anything else.  Why artificially limit this? We
have the description in its totality on the hard-drive, there is no real
latency issues we have to deal with... we need to be careful how we decide
upon limiting otherwise immediate information.

Personally i think the item-view is not terribly wrong, but to improve it
the big challenge is dealing with what information should be contextual and
what should be static, which buttons/links/data are necessary all of the
time and what is necessary in specific circumstances.

PS: I am loving the mailing list activity.


Cheers,
matt m

On Sun, Jun 19, 2011 at 12:03 PM, Aaron Peachey <alpeachey@xxxxxxxxx> wrote:

> On Sat, Jun 18, 2011 at 4:12 AM, Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>
> wrote:
> > I drew a wireframe adding these three things to the existing layout.
> > Then I tried a major rearrangement to see if I could find a better
> layout.
> > <
> https://wiki.ubuntu.com/SoftwareCenter?action=AttachFile&do=view&target=p58-small.png
> >
> > <
> https://wiki.ubuntu.com/SoftwareCenter?action=AttachFile&do=view&target=p59-small.png
> >
> > (second attempt at the major rearrangement)
> I like it. However, with the metadata in a 'left margin' but it
> results in a lot of wasted space in that left hand margin underneath.
> Perhaps we could add something else (e.g. reviews or recommendations)
> below that?
>
> > *   The installation state bar is gone, replaced by an "Install for
> >    Free", "Buy for $X", or "Remove" button under the summary (like in
> >    USC 2.0).
> >    !   This would require figuring out where to put the other stuff
> >        that appears in that bar, like progress bars and error messages.
> I don't know why this layout precludes us from having the bar. It
> seems like it should be fine to keep it.
> But if so, I'm thinking we could move the average rating from
> right-aligned to immediately follow the application name and then have
> the progress bar right aligned at the top level when it is in use.
>
> > *   The description is collapsed down to a single paragraph or so, with
> >    the rest available by clicking an expander.
> I like this but think we should determine the optimum paragraph size
> so that the chance of needing to click the expander is minimised for
> most applications.
>
> > *   The technical metadata (package name, version, size, license etc) is
> >    moved into a column by itself, below the icon.
> >    +   This would reduce the scrolling required to get to reviews (or,
> >        for that matter, to get to the metadata).
> I agree, the metadata near the top is a good idea
> As above, I think there is an opportunity to put reviews in the margin
> itself. (I can mock this up if it doesn't make sense in written form).
>
> >    -   It would work poorly for long package names.
> Do we need to consider the value of the package name being shown by
> default? Personally, I only use package names when I am searching for
> something I've seen on the web, but in most cases I use apt-get for
> these anyway so the package name in USC is superfluous to me.
> I think our search should still use the package name but wonder what
> use cases we have for it being in the app details screen by default?
>
> > *   The "Reviews" section shows the average rating (as well as the
> >    distribution of ratings). This conflicts with showing it at the top
> >    of the screen, though.
> >
> I like the distribution of ratings idea.
> It doesn't make sense to have the average rating in two places,
> especially if the top section stays fixed on scrolling.
> Showing only the single 'most useful' review by default is an issue I
> think. The usefulness of that review becomes self-perpetuating as it
> is shown by default and already has a history of being useful, it is
> more likely to have its usefulness rating increase while reviews that
> are not shown are destined never to reach top position. (We already
> show the most useful review at the top, so this issue already exists
> in some form, but I believe it would be worse if we only showed 1)
>
> cheers
> Aaron
>
> _______________________________________________
> Mailing list: https://launchpad.net/~software-store-developers
> Post to     : software-store-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~software-store-developers
> More help   : https://help.launchpad.net/ListHelp
>



-- 
>From the mind of me!