🆕 Apps "Discover" section: Showcasing app ecosystem inside the app store

[jancborchardt]

As we have more and more apps, the app store makes it more and more difficult to find relevant content or featured apps. A mechanism to solve this could be a new "Discover" section as the main entry.

This would be to feature not just apps, but generally content, like the "Today" tab in the iOS app store: https://developer.apple.com/app-store/discoverability/

• We already have plenty of content on our blog like interviews, podcasts, developer stuff etc. that we can use.
• Similarly we can have "5 recommended productivity apps" etc, just groups of apps with a little text alongside it which can initially be our "app bundles" but presented in a much nicer way
• 5 top-rated apps (recently and/or all-time)
• Much more content

This does not need to always be updated but can be circled around every once in a while (this is done in the iOS App Store Today tab as well).

An example of that was in this mockup for the new online app store where we thought about inserting content like that inbetween the apps. But this would be a full-on way to discover apps.

Also ref related "new in Nextcloud": #9165

[AndyScherzinger]

@jancborchardt I suspect when having to be implemented for the apps / store section within an Nextcloud instance you also want this in the actual store frontend on apps.nc.c - right?

[jancborchardt]

@AndyScherzinger would be a separate step and not tied to a release, but yes ideally and for more reach, it eventually is also on there.

Already discussed this with @szaimen as well – to keep it in mind, but also to focus on the specs for the internal apps mgmt as that is release-dependent.

[AndyScherzinger]

@jancborchardt well, the questions will be

• where does the data come from and
• where is the information what to actually display (since this needs to be maintained in some way)

In other words: how will any frontend decide what to show and my guess it being something curated: who is doing this where?

[jancborchardt]

@szaimen generally looks nice, would be good to have some supportive text and also more examples, e.g. an interview and a list/bundle, and also see what happens when it's clicked. (Both could open a modal for example.)

---

@AndyScherzinger possible examples are loosely defined above in the original post:

This would be to feature not just apps, but generally content, like the "Today" tab in the iOS app store: https://developer.apple.com/app-store/discoverability/

• We already have plenty of content on our blog like interviews, podcasts, developer stuff etc. that we can use.
• Similarly we can have "5 recommended productivity apps" etc, just groups of apps with a little text alongside it which can initially be our "app bundles" but presented in a much nicer way
• 5 top-rated apps (recently and/or all-time)
• Much more content

Since we don't have to have this always freshly updated but we are sending requests to the app store here anyway we can either ship the content or call it from the app store server.
That's really a decision for you though @sorbaugh @AndyScherzinger ?

[szaimen]

@szaimen generally looks nice, would be good to have some supportive text and also more examples, e.g. an interview and a list/bundle, and also see what happens when it's clicked. (Both could open a modal for example.)

working on that 👍

[AndyScherzinger]

That's really a decision for you though @sorbaugh @AndyScherzinger ?

Well, for me this starts with the question

• Who is maintaining this content?

Because this will set the direction for where to find it and how to best retrieve it. To me what we display on a "Today" page on any store frontend should be maintained by Marketing or Communication (being an Engineering I still sometimes have a hard time to tell which one is the correct one). What do you think @karlitschek @jospoortvliet - helping out a communication/marketing noob.

[sorbaugh]

Unless I'm thinking too complicated, to me this reminiscent of a content-page, or in other words engineers build the frontend structure while a "content team" (marketing, communication) that updates the content every once in a while and it gets displayed. "Every once in a while" needs to be defined. Does it mean every realease? Does it mean whenever the "content team" wants to make a change?. This affects the architectural decision.

[szaimen]

Hi everyone,

I finally managed to finish the mockup. This is how it looks now:

Desktop	Mobile

The content itself will be managed by the marketing team (so the items shown above are only examples to showcase the layouts).

From frontend perspective we basically have two layouts, one for things like podcasts and news stuff with a big picture on one side and a heading and text on the other side. The other layout is a five cards-layout with a heading that can be used to list apps or other content in a cards-layout.

When clicking on things like podcasts and new stuff element, it should directly open a new page and link to the corresponding blogpost. When clicking on an app, it should open the sidebar with more info about that app.

Please let me know what you think and if you need further input. Thank you! :)

[susnux]

From the mock ups I see following needed data:

{
    type: "", // either "post" or "showcase"
    headline: {}, // localized title, maybe an mapping { "de": "Faszinierende Wallpaper", "en": "Amazing wallpapers" }
    text: {}, // localized "preview" text, maybe like headline
    link: "", // to the full blog post / podcast etc
    image: "" // image to show for posts
    apps: [] // for show cases (maybe generic in some "parameters" or "data" property)
}[]

Maybe also an date or expiryDate property to expire content.

So this can be fetched from the app-store, images should be cached by the local Nextcloud instance (just download images in appdata?).

[szaimen]

I just created a few more types that we might use in the future:

[susnux]

For the carousel: Only show the arrows on hover?
Should it auto-shuffle after ~5s ~10s?

[szaimen]

For the carousel: Only show the arrows on hover?

Yes, if possible and not against a11y best practices.

Should it auto-shuffle after ~5s ~10s?

Yeah, maybe ever 10s? WDYT @jospoortvliet

[susnux]

Yes, if possible and not against a11y best practices.

No I do not think so - as long as they are focusable and the hover box is big enough I do not see any issues.
Asking because I think the arrows are a bit too "prominent" when always shown - but thats just my personal feeling 😉

[szaimen]

Instead of hiding we maybw could use --text-maxcontrast for these elements which might already fix the too prominent problem?

[jospoortvliet]

Don't switch too fast. 10 sec might already be quite fast, but maybe see what apple does, or google...

[jospoortvliet]

But overall, very nice work. I look forward to the first implementation!

[jancborchardt]

Very nice! :)

One main point of feedback: We shouldn’t use carousels so much as they are not particularly discoverable nor accessible. Scrolling vertically is fine, but trying to cram so much in by just hiding it behind carousels makes it obscure.
There’s also a reason why e.g. the macOS / iOS app store uses horizontal scrolling basically only for images on the detail page and reviews, cause those could be potentially a lot. Also there they tease the start of the next element on the sides.

[szaimen]

🎉🎉🎉

[susnux]

Reopen due to "show case" type is missing and will be added with the next beta.