Dev recommendations on MDN App Center: call for feedback on UX

Hi all,

Liz (cc=92d) and I have done some work on dev recommendations[1] for the =
MDN App Center[2], specifically thinking about the UX of these =
recommendations - how they will be presented on App Center subpages.

Essentially, we want to provide developers with recommendations on how =
to understand a topic to solve a problem as quickly as possible, without =
having to wade through tonnes of tutorials/guides. Think =93My boss =
wants me to implement this in a week. I just need a solution that =
works.=94 I produced a prototype[3] to show what kind of thing we were =
after. We present the quick solutions/recommendations first, and then =
only after that do we present more detailed tutorials and references, =
for those that need to dig deeper.

But we wanted to make the diagram more interactive, and provide FAQ =
boxes that would link to solutions to common problems (on Stackoverflow, =
or other suitable places). To this end, Liz created some interactive UX =
prototypes[4].

Questions:

1. Does this make sense overall?
2. What UX option do we prefer? Option 1 is the recommended way, which I =
agree with too (being a fan of simple but effective solutions!), but you =
might have some different ideas
3. Are there any content types missing from [3] that you feel need to be =
thought about?

Have a look and see what you think. Feedback welcome. Please submit =
feedback by April 8th, after which we will begin implementation unless =
we hear any major voices of dissent.

Thanks for listening!

Chris Mills
   Senior tech writer || Mozilla
developer.mozilla.org || MDN
   cmills@mozilla.com || @chrisdavidmills


[1] =
https://groups.google.com/forum/#!searchin/mozilla.dev.webapps/developer$2=
0recommendations/mozilla.dev.webapps/bKdiY8ziCrw/LUCrL015150J
[2] https://developer.mozilla.org/en-US/Apps
[3] https://developer.mozilla.org/en-US/Apps/Build/Offline
[4] http://cauj20.axshare.com/#p=3Dindex

0
Chris
4/1/2014 5:41:47 PM
mozilla.dev.mdc 2326 articles. 0 followers. Post Follow

6 Replies
1051 Views

Similar Articles

[PageSpeed] 32

On 2014-04-01 17:41:47 +0000, Chris Mills said:

> Essentially, we want to provide developers with recommendations on how 
> to understand a topic to solve a problem as quickly as possible, 
> without having to wade through tonnes of tutorials/guides. Think “My 
> boss wants me to implement this in a week. I just need a solution that 
> works.” I produced a prototype[3] to show what kind of thing we were 
> after. We present the quick solutions/recommendations first, and then 
> only after that do we present more detailed tutorials and references, 
> for those that need to dig deeper.
> 
> But we wanted to make the diagram more interactive, and provide FAQ 
> boxes that would link to solutions to common problems (on 
> Stackoverflow, or other suitable places). To this end, Liz created some 
> interactive UX prototypes[4].
> 
> Questions:
> 
> 1. Does this make sense overall?
> 2. What UX option do we prefer? Option 1 is the recommended way, which 
> I agree with too (being a fan of simple but effective solutions!), but 
> you might have some different ideas
> 3. Are there any content types missing from [3] that you feel need to 
> be thought about?
> 
> Have a look and see what you think. Feedback welcome. Please submit 
> feedback by April 8th, after which we will begin implementation unless 
> we hear any major voices of dissent.

So here's my feeling:

First, I like the direction here, by and large. I do have questions and 
suggestions:

1. I would personally prefer there to be more text before you get to a 
flowchart. Charts make me think "this page is promo material" and tune 
out, if there's not something before them to catch my interest. Just a 
thought, not a big deal.

2. I like the per-section FAQ concept as long as we can keep the number 
of FAQs under control, and can design the boxes for them to be able to 
be "rolled up" out of the way while reading if you're not looking for 
them.

3. We have been trying to move the "See also" section (which you've 
labeled "Additional Information" in this mockup) into the sidebar as 
quicklinks. We should do that here.

-- 
Eric Shepherd
Developer Documentation Lead
Mozilla
Blog: http://www.bitstampede.com/
Twitter: @sheppy

0
Eric
4/2/2014 5:55:34 PM
On 2 Apr 2014, at 18:55, Eric Shepherd <eshepherd@mozilla.com> wrote:

> On 2014-04-01 17:41:47 +0000, Chris Mills said:
>=20
>> Essentially, we want to provide developers with recommendations on =
how to understand a topic to solve a problem as quickly as possible, =
without having to wade through tonnes of tutorials/guides. Think =93My =
boss wants me to implement this in a week. I just need a solution that =
works.=94 I produced a prototype[3] to show what kind of thing we were =
after. We present the quick solutions/recommendations first, and then =
only after that do we present more detailed tutorials and references, =
for those that need to dig deeper.
>> But we wanted to make the diagram more interactive, and provide FAQ =
boxes that would link to solutions to common problems (on Stackoverflow, =
or other suitable places). To this end, Liz created some interactive UX =
prototypes[4].
>> Questions:
>> 1. Does this make sense overall?
>> 2. What UX option do we prefer? Option 1 is the recommended way, =
which I agree with too (being a fan of simple but effective solutions!), =
but you might have some different ideas
>> 3. Are there any content types missing from [3] that you feel need to =
be thought about?
>> Have a look and see what you think. Feedback welcome. Please submit =
feedback by April 8th, after which we will begin implementation unless =
we hear any major voices of dissent.
>=20
> So here's my feeling:
>=20
> First, I like the direction here, by and large. I do have questions =
and suggestions:
>=20
> 1. I would personally prefer there to be more text before you get to a =
flowchart. Charts make me think "this page is promo material" and tune =
out, if there's not something before them to catch my interest. Just a =
thought, not a big deal.

This is interesting, and I=92d like to find out if anyone else has the =
same kind of concerns. To my mind, it is all about context - if it were =
just a flashy chart with no promise of further use material, then yes, =
but here we have the TOC, plus the article abstract should give readers =
a clue straight away.

On that subject, I=92ve added some details to the abstract to make the =
page=92s merits more explicit. Do you think this helps?

>=20
> 2. I like the per-section FAQ concept as long as we can keep the =
number of FAQs under control, and can design the boxes for them to be =
able to be "rolled up" out of the way while reading if you're not =
looking for them.

We are intentionally keeping each FAQ box really short - ideally 3-5 =
FAQs and 1-2 links to further information (probably to the best place on =
SO, for example) - to make them as unobtrusive as possible. Do you think =
they still need to be collapsable? I could understand it if they were =
longer.



>=20
> 3. We have been trying to move the "See also" section (which you've =
labeled "Additional Information" in this mockup) into the sidebar as =
quicklinks. We should do that here.

Ah, I hadn=92t noticed that the stuff under the recommendations had been =
grouped under =93Additional information=94 in the UX mockup ;-)

Yes, this is a cool idea - I like the thought of putting these =
additional bits of info in the quicklinks, to make the page even shorter =
and even less intimidating. How would the quicklinks display - on top of =
the left hand menu, or instead of?

And how would I create the quicklinks? In the same way as the subnav? Or =
would I need a macro?=
0
Chris
4/3/2014 9:35:40 AM
Hi Chris, Eric, all,

I agree that more text before the flowchart and after the article abstract
would make the page less "promo material" and more informative: I would
introduce a further section, say "Offline Apps Overview", in which
inserting a simple description of the flowchart and the flowchart itself.
Does it make sense?

About FAQs, I like the idea! And it would nice to have FAQs also in the
"Gather and Modify Data" section [1]. Option 1 is ok: what about adding
general FAQs about offline apps, about where, when and why I should make
them offline? Actually maybe I mean Use Cases more that FAQs, which might
be inserted in the "Offline Apps Overview", or somewhere else.

Regarding the "Examples" section, that is TBD, is there any article in MDN
explaining the code of an offline demo app? It might be linked from here.

Hope it helps!

Best,

Francesco <https://developer.mozilla.org/en-US/profiles/franciov>


Francesco <http://www.francesco.iovine.name/>


On 3 April 2014 11:35, Chris Mills <cmills@mozilla.com> wrote:

> On 2 Apr 2014, at 18:55, Eric Shepherd <eshepherd@mozilla.com> wrote:
>
> > On 2014-04-01 17:41:47 +0000, Chris Mills said:
> >
> >> Essentially, we want to provide developers with recommendations on how
> to understand a topic to solve a problem as quickly as possible, without
> having to wade through tonnes of tutorials/guides. Think "My boss wants me
> to implement this in a week. I just need a solution that works." I produced
> a prototype[3] to show what kind of thing we were after. We present the
> quick solutions/recommendations first, and then only after that do we
> present more detailed tutorials and references, for those that need to dig
> deeper.
> >> But we wanted to make the diagram more interactive, and provide FAQ
> boxes that would link to solutions to common problems (on Stackoverflow, or
> other suitable places). To this end, Liz created some interactive UX
> prototypes[4].
> >> Questions:
> >> 1. Does this make sense overall?
> >> 2. What UX option do we prefer? Option 1 is the recommended way, which
> I agree with too (being a fan of simple but effective solutions!), but you
> might have some different ideas
> >> 3. Are there any content types missing from [3] that you feel need to
> be thought about?
> >> Have a look and see what you think. Feedback welcome. Please submit
> feedback by April 8th, after which we will begin implementation unless we
> hear any major voices of dissent.
> >
> > So here's my feeling:
> >
> > First, I like the direction here, by and large. I do have questions and
> suggestions:
> >
> > 1. I would personally prefer there to be more text before you get to a
> flowchart. Charts make me think "this page is promo material" and tune out,
> if there's not something before them to catch my interest. Just a thought,
> not a big deal.
>
> This is interesting, and I'd like to find out if anyone else has the same
> kind of concerns. To my mind, it is all about context - if it were just a
> flashy chart with no promise of further use material, then yes, but here we
> have the TOC, plus the article abstract should give readers a clue straight
> away.
>
> On that subject, I've added some details to the abstract to make the
> page's merits more explicit. Do you think this helps?
>
> >
> > 2. I like the per-section FAQ concept as long as we can keep the number
> of FAQs under control, and can design the boxes for them to be able to be
> "rolled up" out of the way while reading if you're not looking for them.
>
> We are intentionally keeping each FAQ box really short - ideally 3-5 FAQs
> and 1-2 links to further information (probably to the best place on SO, for
> example) - to make them as unobtrusive as possible. Do you think they still
> need to be collapsable? I could understand it if they were longer.
>
>
>
> >
> > 3. We have been trying to move the "See also" section (which you've
> labeled "Additional Information" in this mockup) into the sidebar as
> quicklinks. We should do that here.
>
> Ah, I hadn't noticed that the stuff under the recommendations had been
> grouped under "Additional information" in the UX mockup ;-)
>
> Yes, this is a cool idea - I like the thought of putting these additional
> bits of info in the quicklinks, to make the page even shorter and even less
> intimidating. How would the quicklinks display - on top of the left hand
> menu, or instead of?
>
> And how would I create the quicklinks? In the same way as the subnav? Or
> would I need a macro?
> _______________________________________________
> dev-mdc mailing list
> dev-mdc@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-mdc
>
0
Francesco
4/4/2014 10:18:09 AM
On 4 Apr 2014, at 11:18, Francesco Iovine <f.iovine@gmail.com> wrote:

> Hi Chris, Eric, all,
>=20
> I agree that more text before the flowchart and after the article =
abstract would make the page less "promo material" and more informative: =
I would introduce a further section, say "Offline Apps Overview", in =
which inserting a simple description of the flowchart and the flowchart =
itself. Does it make sense?

Have a look at the page again - I=92ve instead more of a description =
before the diagram appears. Does this improve the situation? I am a bit =
wary of adding any more text up here, because it starts to defeat the =
point of getting to an answer quickly.

>=20
> About FAQs, I like the idea! And it would nice to have FAQs also in =
the "Gather and Modify Data" section [1]. Option 1 is ok: what about =
adding general FAQs about offline apps, about where, when and why I =
should make them offline? Actually maybe I mean Use Cases more that =
FAQs, which might be inserted in the "Offline Apps Overview", or =
somewhere else.

I definitely want to repeat this pattern for =93gather and modify data=94,=
 and for other sections of the app center. If you want to write some =
content for that landing page in the same kind of structure, then please =
do! ;-)

For general FAQs, we might this stuff at the bottom of the page if it is =
deemed necessary, but again, I am worried about more noise to get =
between the reader and the answers.

As you say, that kind of question could be answered in some kind of Use =
cases section, which could perhaps just be put inside=20

>=20
> Regarding the "Examples" section, that is TBD, is there any article in =
MDN explaining the code of an offline demo app? It might be linked from =
here.
>=20

I=92ve added a couple of IndexedDB examples from the IndexedDB reference =
page, but really here we need an example that follows the dev =
recommendations and shows a best practices app that does all of this =
stuff.

> Hope it helps!
>=20
> Best,
>=20
> Francesco
>=20
>=20
> Francesco
>=20
>=20
> On 3 April 2014 11:35, Chris Mills <cmills@mozilla.com> wrote:
> On 2 Apr 2014, at 18:55, Eric Shepherd <eshepherd@mozilla.com> wrote:
>=20
> > On 2014-04-01 17:41:47 +0000, Chris Mills said:
> >
> >> Essentially, we want to provide developers with recommendations on =
how to understand a topic to solve a problem as quickly as possible, =
without having to wade through tonnes of tutorials/guides. Think =93My =
boss wants me to implement this in a week. I just need a solution that =
works.=94 I produced a prototype[3] to show what kind of thing we were =
after. We present the quick solutions/recommendations first, and then =
only after that do we present more detailed tutorials and references, =
for those that need to dig deeper.
> >> But we wanted to make the diagram more interactive, and provide FAQ =
boxes that would link to solutions to common problems (on Stackoverflow, =
or other suitable places). To this end, Liz created some interactive UX =
prototypes[4].
> >> Questions:
> >> 1. Does this make sense overall?
> >> 2. What UX option do we prefer? Option 1 is the recommended way, =
which I agree with too (being a fan of simple but effective solutions!), =
but you might have some different ideas
> >> 3. Are there any content types missing from [3] that you feel need =
to be thought about?
> >> Have a look and see what you think. Feedback welcome. Please submit =
feedback by April 8th, after which we will begin implementation unless =
we hear any major voices of dissent.
> >
> > So here's my feeling:
> >
> > First, I like the direction here, by and large. I do have questions =
and suggestions:
> >
> > 1. I would personally prefer there to be more text before you get to =
a flowchart. Charts make me think "this page is promo material" and tune =
out, if there's not something before them to catch my interest. Just a =
thought, not a big deal.
>=20
> This is interesting, and I=92d like to find out if anyone else has the =
same kind of concerns. To my mind, it is all about context - if it were =
just a flashy chart with no promise of further use material, then yes, =
but here we have the TOC, plus the article abstract should give readers =
a clue straight away.
>=20
> On that subject, I=92ve added some details to the abstract to make the =
page=92s merits more explicit. Do you think this helps?
>=20
> >
> > 2. I like the per-section FAQ concept as long as we can keep the =
number of FAQs under control, and can design the boxes for them to be =
able to be "rolled up" out of the way while reading if you're not =
looking for them.
>=20
> We are intentionally keeping each FAQ box really short - ideally 3-5 =
FAQs and 1-2 links to further information (probably to the best place on =
SO, for example) - to make them as unobtrusive as possible. Do you think =
they still need to be collapsable? I could understand it if they were =
longer.
>=20
>=20
>=20
> >
> > 3. We have been trying to move the "See also" section (which you've =
labeled "Additional Information" in this mockup) into the sidebar as =
quicklinks. We should do that here.
>=20
> Ah, I hadn=92t noticed that the stuff under the recommendations had =
been grouped under =93Additional information=94 in the UX mockup ;-)
>=20
> Yes, this is a cool idea - I like the thought of putting these =
additional bits of info in the quicklinks, to make the page even shorter =
and even less intimidating. How would the quicklinks display - on top of =
the left hand menu, or instead of?
>=20
> And how would I create the quicklinks? In the same way as the subnav? =
Or would I need a macro?
> _______________________________________________
> dev-mdc mailing list
> dev-mdc@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-mdc
>=20

0
Chris
4/7/2014 8:59:13 AM
On 7 April 2014 10:59, Chris Mills <cmills@mozilla.com> wrote:

>
> On 4 Apr 2014, at 11:18, Francesco Iovine <f.iovine@gmail.com> wrote:
>
> > Hi Chris, Eric, all,
> >
> > I agree that more text before the flowchart and after the article
> abstract would make the page less "promo material" and more informative: I
> would introduce a further section, say "Offline Apps Overview", in which
> inserting a simple description of the flowchart and the flowchart itself.
> Does it make sense?
>
> Have a look at the page again - I've instead more of a description before
> the diagram appears. Does this improve the situation? I am a bit wary of
> adding any more text up here, because it starts to defeat the point of
> getting to an answer quickly.
>

*Yea, it looks much better *to me*, but you're right: now the diagram is
not the first thing readers look at anymore. *


>
> >
> > About FAQs, I like the idea! And it would nice to have FAQs also in the
> "Gather and Modify Data" section [1]. Option 1 is ok: what about adding
> general FAQs about offline apps, about where, when and why I should make
> them offline? Actually maybe I mean Use Cases more that FAQs, which might
> be inserted in the "Offline Apps Overview", or somewhere else.
>
> I definitely want to repeat this pattern for "gather and modify data", and
> for other sections of the app center. If you want to write some content for
> that landing page in the same kind of structure, then please do! ;-)
>

*I will ;)*


>
> For general FAQs, we might this stuff at the bottom of the page if it is
> deemed necessary, but again, I am worried about more noise to get between
> the reader and the answers.
>
> As you say, that kind of question could be answered in some kind of Use
> cases section, which could perhaps just be put inside
>

*Yes, I think a Use cases section and also some context/history about the
different offline storage techniques would help reader choosing the best
solution for each use case / app.*


>
> >
> > Regarding the "Examples" section, that is TBD, is there any article in
> MDN explaining the code of an offline demo app? It might be linked from
> here.
> >
>
> I've added a couple of IndexedDB examples from the IndexedDB reference
> page, but really here we need an example that follows the dev
> recommendations and shows a best practices app that does all of this stuff.
>

*I think I can make it.*


>
> > Hope it helps!
> >
> > Best,
> >
> > Francesco
> >
> >
> > Francesco
> >
> >
> > On 3 April 2014 11:35, Chris Mills <cmills@mozilla.com> wrote:
> > On 2 Apr 2014, at 18:55, Eric Shepherd <eshepherd@mozilla.com> wrote:
> >
> > > On 2014-04-01 17:41:47 +0000, Chris Mills said:
> > >
> > >> Essentially, we want to provide developers with recommendations on
> how to understand a topic to solve a problem as quickly as possible,
> without having to wade through tonnes of tutorials/guides. Think "My boss
> wants me to implement this in a week. I just need a solution that works." I
> produced a prototype[3] to show what kind of thing we were after. We
> present the quick solutions/recommendations first, and then only after that
> do we present more detailed tutorials and references, for those that need
> to dig deeper.
> > >> But we wanted to make the diagram more interactive, and provide FAQ
> boxes that would link to solutions to common problems (on Stackoverflow, or
> other suitable places). To this end, Liz created some interactive UX
> prototypes[4].
> > >> Questions:
> > >> 1. Does this make sense overall?
> > >> 2. What UX option do we prefer? Option 1 is the recommended way,
> which I agree with too (being a fan of simple but effective solutions!),
> but you might have some different ideas
> > >> 3. Are there any content types missing from [3] that you feel need to
> be thought about?
> > >> Have a look and see what you think. Feedback welcome. Please submit
> feedback by April 8th, after which we will begin implementation unless we
> hear any major voices of dissent.
> > >
> > > So here's my feeling:
> > >
> > > First, I like the direction here, by and large. I do have questions
> and suggestions:
> > >
> > > 1. I would personally prefer there to be more text before you get to a
> flowchart. Charts make me think "this page is promo material" and tune out,
> if there's not something before them to catch my interest. Just a thought,
> not a big deal.
> >
> > This is interesting, and I'd like to find out if anyone else has the
> same kind of concerns. To my mind, it is all about context - if it were
> just a flashy chart with no promise of further use material, then yes, but
> here we have the TOC, plus the article abstract should give readers a clue
> straight away.
> >
> > On that subject, I've added some details to the abstract to make the
> page's merits more explicit. Do you think this helps?
> >
> > >
> > > 2. I like the per-section FAQ concept as long as we can keep the
> number of FAQs under control, and can design the boxes for them to be able
> to be "rolled up" out of the way while reading if you're not looking for
> them.
> >
> > We are intentionally keeping each FAQ box really short - ideally 3-5
> FAQs and 1-2 links to further information (probably to the best place on
> SO, for example) - to make them as unobtrusive as possible. Do you think
> they still need to be collapsable? I could understand it if they were
> longer.
> >
> >
> >
> > >
> > > 3. We have been trying to move the "See also" section (which you've
> labeled "Additional Information" in this mockup) into the sidebar as
> quicklinks. We should do that here.
> >
> > Ah, I hadn't noticed that the stuff under the recommendations had been
> grouped under "Additional information" in the UX mockup ;-)
> >
> > Yes, this is a cool idea - I like the thought of putting these
> additional bits of info in the quicklinks, to make the page even shorter
> and even less intimidating. How would the quicklinks display - on top of
> the left hand menu, or instead of?
> >
> > And how would I create the quicklinks? In the same way as the subnav? Or
> would I need a macro?
> > _______________________________________________
> > dev-mdc mailing list
> > dev-mdc@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-mdc
> >
>
>
0
Francesco
4/7/2014 11:14:39 AM

On 7 Apr 2014, at 12:14, Francesco Iovine <f.iovine@gmail.com> wrote:

>=20
>=20
> On 7 April 2014 10:59, Chris Mills <cmills@mozilla.com> wrote:
>=20
> On 4 Apr 2014, at 11:18, Francesco Iovine <f.iovine@gmail.com> wrote:
>=20
> > Hi Chris, Eric, all,
> >
> > I agree that more text before the flowchart and after the article =
abstract would make the page less "promo material" and more informative: =
I would introduce a further section, say "Offline Apps Overview", in =
which inserting a simple description of the flowchart and the flowchart =
itself. Does it make sense?
>=20
> Have a look at the page again - I=92ve instead more of a description =
before the diagram appears. Does this improve the situation? I am a bit =
wary of adding any more text up here, because it starts to defeat the =
point of getting to an answer quickly.
>=20
> Yea, it looks much better *to me*, but you're right: now the diagram =
is not the first thing readers look at anymore.=20
> =20
>=20
> >
> > About FAQs, I like the idea! And it would nice to have FAQs also in =
the "Gather and Modify Data" section [1]. Option 1 is ok: what about =
adding general FAQs about offline apps, about where, when and why I =
should make them offline? Actually maybe I mean Use Cases more that =
FAQs, which might be inserted in the "Offline Apps Overview", or =
somewhere else.
>=20
> I definitely want to repeat this pattern for =93gather and modify =
data=94, and for other sections of the app center. If you want to write =
some content for that landing page in the same kind of structure, then =
please do! ;-)
>=20
> I will ;)
> =20
>=20
> For general FAQs, we might this stuff at the bottom of the page if it =
is deemed necessary, but again, I am worried about more noise to get =
between the reader and the answers.
>=20
> As you say, that kind of question could be answered in some kind of =
Use cases section, which could perhaps just be put inside
>=20
> Yes, I think a Use cases section and also some context/history about =
the different offline storage techniques would help reader choosing the =
best solution for each use case / app.
> =20
>=20
> >
> > Regarding the "Examples" section, that is TBD, is there any article =
in MDN explaining the code of an offline demo app? It might be linked =
from here.
> >
>=20
> I=92ve added a couple of IndexedDB examples from the IndexedDB =
reference page, but really here we need an example that follows the dev =
recommendations and shows a best practices app that does all of this =
stuff.
>=20
> I think I can make it.
> =20

This was be super awesome. It might make sense for me to start up a =
dialog between you and some of our web apps folk that know a lot about =
offline apps, to see if we can reach a consensus on best practices for =
this, and work towards building a decent example.

0
Chris
4/7/2014 11:30:05 AM
Reply: