ubuntu-appstore-developers team mailing list archive

[Michał Sawicz <michal.sawicz@xxxxxxxxxxxxx>]

On 22.04.2014 16:40, Alejandro J. Cura wrote:
> On Tue, Apr 22, 2014 at 9:47 AM, Martin Albisetti
> <martin.albisetti@xxxxxxxxxxxxx> wrote:
>> On Mon, Apr 21, 2014 at 8:09 PM, Alejandro J. Cura
>> <alejandro.cura@xxxxxxxxxxxxx> wrote:
>>> So, there seems to be room for improvement if the scope would pass the
>>> desired size in pixels of Icons and Screenshots when making webcalls,
>>> and if the server would take that as a hint to return urls to resized
>>> images.
>>
>> I understand the problem.
>> The reason we don't already do this, is because programatically
>> resizing images without making beautifully crafted images ugly is hard
>> and rarely works. In fact, I've had to fight off the increase of the
>> default size from 256 to 512   :)
>> We already allow users to upload smaller sizes, you could be getting
>> those instead when available. In order to increase the chances they'll
>> be available, we could add a "generate all sizes" button in the UI for
>> developers and let them decide if they're happy with the automatic
>> result.
>> That way we don't force developers to provide every single possible
>> size, but still increase the chance there will be smaller sizes.
>>
>> If we feel this is a big problem, I'd probably suggest we make smaller
>> sizes mandatory (and with file size limits) so they're available when
>> and how we need them.
> 
> I agree that automatically resized images do not look great, but yes,
> allowing to "generate all sizes" sounds like a good option to lower
> the barrier for solo developers, so +1 to that.
> And setting maximum file sizes for each icon resolution sounds like a
> good plan too: quite a few of the icons in the store would benefit
> from being jpeg instead of png, for instance. Do we support this?
> 
> Now, what would be the best place in our software stack to choose
> among the available icon sizes?
> We do not want the webservice to be sending the list of all available
> icon urls with each result, and we don't want the scope or dash to
> have hardcoded icon sizes to choose from, so my suggestion is:
> 
> - the dash tells the scope the requested width when doing a search
> - the scope passes that to the webservice
> - the webservice uses that as a hint to select the next-biggest size
> and return the appropriate url.

I'm afraid that's not an option. The UI only knows the size of the image
needed when creating the delegate for it, since it doesn't know what
will the layout be when searching. I agree pushing the whole set of
available sizes isn't good, either.

I think the best way would be for the requested size to actually be part
of the URL that the UI can then mangle to include the minimum size it
wants the image to be - the webservice would then return the next-bigger
size.

>> I would also suggest following a bit of what's done in websites, where
>> you do lazy loading of images[1], prioritise what's visible on the
>> screen and start loading the next ones once that completes, in
>> batches. The infrastructure may not be available in scopes, but I
>> would certainly suggest it gets added to a ToDo somewhere  :)
> 
> Afaict, that's already done by the dash: only the visible icons are
> loaded, and more are loaded when swiping the results.

Yeah, they are. We're not pre-loading those off-screen, though.

-- 
Michał (Saviq) Sawicz <michal.sawicz@xxxxxxxxxxxxx>
Canonical Services Ltd.

Attachment: signature.asc
Description: OpenPGP digital signature