796036 - Design App Generator v1

Status: RESOLVED FIXED

(Marketplace Graveyard :: Developer Pages, defect)

Description

[Daniel Buchner [:dbuc]]

Let's develop an app generator that spits out skeletal app packages so our developers can get to coding with a quickness!

Comment 1

[Matt Basta [:basta]]

Isn't this what Mortar is for? Or is this bug to create for apps what the Add-on Builder is for add-ons?

Also, http://testpackagedapp.appspot.com/ kind of does this already.

Comment 2

[Christopher Van Wiemeersch [:cvan]]

So what I think you're describing is the GitHub Packaged-App Amazing-Fantastic Uploader.

Comment 3

[Daniel Buchner [:dbuc]]

The App Generator is the page that offers a bit more, but does utilize volo/mortar. The App Generator is essentially a form that proceeds stepwise as follows:

1. What Type of App/Package are You Building?

This will be a select list that offers many different vertical choices, like game, books/magazines, social, productivity, etc

2. Choose a Layout

Options available in this step are filter by the developer's choice in Step 1. These layout options will be presented as a grid of layouts (a sketch-like image of the rough layout + a name and description), and when the developer chooses an option, the packager is instructed to include the files relevant to that layout.


3. Add Assets

A list of optional includes (JS libraries, modules), specific to the vertical selected.


4. Compression

Should be minify the assets included in the package

5. Overview

What has been included and an option to build the package

Result:

User should be provided a download of a zip file that includes all the files required to start an app. The package should be hashed so that the user can enter the hash in an input on the page to call up the configuration if they need to review or modify it at a later date.

Comment 4

[Christopher Van Wiemeersch [:cvan]]

(In reply to Daniel Buchner [:dbuc] from comment #3)
> 4. Compression
> 
> Should be minify the assets included in the package

That will be a PITA for reviewers to review minified code.

Comment 5

[Fred Wenzel [:wenzel]]

(In reply to Chris Van Wiemeersch [:cvan] from comment #4)
> That will be a PITA for reviewers to review minified code.

Isn't that the same issue for all apps? Minified jquery etc?

Comment 6

[Fred Wenzel [:wenzel]]

(In reply to Matt Basta [:basta] from comment #1)
> Isn't this what Mortar is for?

The app generator is a fancy download page for mortar templates.

Comment 7

[Andy McKay]

You can set up the reviewer tools to ignore certain hashes. So as long as the code is minified consistently (and the hashes kept up to date) it's not a problem.

Comment 8

[James Long (:jlongster)]

Isn't it a little early to be doing this? We still aren't exactly sure what the core components of mortar are yet.

We really only have two types of apps: games, and everything else.

For layouts, I don't think users should be required to choose which ones before they even build their app. That's too much forethought, and then they have to figure out how to add layouts later if they want another one. We should just give them a CSS and js file for all the layouts, which shouldn't be large. A builder might be good, but only if they want to optimize their app when they're ready to push it to production.

Comment 9

[Daniel Buchner [:dbuc]]

Slated for v1 are general layouts (that may fit into multiple categories) and books/magazines. The differences between each are enough that I don't feel having an end-of-Q4 date for this feature is too soon.

Comment 10

[James Long (:jlongster)]

End of Q4 sounds fine, I thought I heard a deadline 2 weeks from now for some reason.

Comment 11

[Matt Basta [:basta]]

Besides the fact that this would put together a template manifest for you, what does it offer over sites like Initializr or the Foundation gallery? Unlike an add-on, we're not talking about very "proprietary" or Firefox-specific features. Apps are effectively websites, so every web boilerplate tool out there to date will work with packaged apps.

I think if we're trying to help developers, better docs would be of better service than a template tool. If a developer is capable of building the JS and markup into a template to make their app work (and handling the zipping/unzipping of the package and potentially modifying the JSON in the manifest), then they'll also be capable of picking out which x-tags and boilerplate they should be using.

Additionally, we shouldn't be leaning users towards packaged apps if their apps don't need to be packaged. It's a lot easier for the editors to review web apps, and frankly it's a lot easier for developers to create web apps than packaged apps.

Comment 12

[Fred Wenzel [:wenzel]]

(In reply to Matt Basta [:basta] from comment #11)
> Additionally, we shouldn't be leaning users towards packaged apps if their
> apps don't need to be packaged.

Agreed. That's not currently in scope for this bug and product.

Comment 13

[Daniel Buchner [:dbuc]]

The tool must cater to multiple developer/creative types. Books and magazines have a very different audience. The content creators in that vertical are far less technical than the type of app developer you infer. There are multitudes of content authors out there right now, who with a layout and a composed starting point, could very easily port/generate content for our Marketplace.

In my mind, the packaged/non-packaged type is an option with a default state that is almost certainly based on the type of layout chosen. (the number of books/mags that consumers want packaged far outweighs the number you don't IMO)

Let's make sure the tool adapts to the developer-type who engages it, instead of making users adapt to a tool crafted for a single segment/skill set.

Comment 14

[James Long (:jlongster)]

Basta brings up a good point. The lack of documentation for x-tags should be higher priority than this. This is something we should build after we already have finished mortar, have docs, and have people using it. Then we can figure out what people really want.

I definitely want to do this, I just can't envision what it looks like yet, but maybe that's just me. Mortar is just going to be a simple bootstrap that can adapt to anything by way of being a simple website. Just add/remove stuff as you would normally in webdev.

Comment 15

[Daniel Buchner [:dbuc]]

(In reply to James Long (:jlongster) from comment #14)
> Basta brings up a good point. The lack of documentation for x-tags should be
> higher priority than this. This is something we should build after we
> already have finished mortar, have docs, and have people using it. Then we
> can figure out what people really want.
> 
> I definitely want to do this, I just can't envision what it looks like yet,
> but maybe that's just me. Mortar is just going to be a simple bootstrap that
> can adapt to anything by way of being a simple website. Just add/remove
> stuff as you would normally in webdev.

I agree to the extent that documentation for supported tags is more important - where I differ is on documentation being a blocker for this effort. The documentation should be able to be generated in lockstep with the layout compositions, and resource contention should not be an issue, as documentation should be the responsibility of another team.

Comment 16

[Daniel Buchner [:dbuc]]

Attachment: App Generator mockup (DRAFT 1)

Comment 17

[Daniel Buchner [:dbuc]]

It is likely that we'll need a per-layout panel of options that shows based on the particular layout the user selects, but I'm thinking v2 for that feature.

Comment 18

[Fred Wenzel [:wenzel]]

Attachment: Mockup feedback

Comment 19

[Fred Wenzel [:wenzel]]

I have some feedback for the mockup. I attached a mockup of my own, not to propose a "competing" design but to illustrate what I am talking about.

1) The dropdown on top is overkill for the two types of apps ("generic app", "game") that we have. I suggest we give people two pics to click on.

2) The mini images illustrating the layouts are good, but won't be enough to tell people what the design is about. I suggest putting a descriptive title underneath AND some bullet points about what this layout does, either on hover or on click.

3) Including individual tags is not what we discussed for v1, partly because it turns the app generator into an on-the-fly generator rather than being able to download pre-built packages. Also, I am not convinced picking individual tags will ever be what people want, since it's hard to know exactly which tags you will need down the road.

I suggest a quick bulleted list with links to what's included in this (or every) template.

4) Manifest builder is a good idea, but not for v1. This too will turn the app generator into an on-the-fly builder, while for now we should stick with pre-built zip files. Once we move past that stage, I think the manifest builder is great and might even be useful outside the app generator, so perhaps we should find a way to make it usable separately while allowing people to build a manifest in this context as well. For v1 though, let's cut this out.

Opinions?

Comment 20

[Daniel Buchner [:dbuc]]

(In reply to Fred Wenzel [:wenzel] from comment #19)
> I have some feedback for the mockup. I attached a mockup of my own, not to
> propose a "competing" design but to illustrate what I am talking about.
> 
> 1) The dropdown on top is overkill for the two types of apps ("generic app",
> "game") that we have. I suggest we give people two pics to click on.
> 

...and Book/Magazine?

> 2) The mini images illustrating the layouts are good, but won't be enough to
> tell people what the design is about. I suggest putting a descriptive title
> underneath AND some bullet points about what this layout does, either on
> hover or on click.
> 

Totally agree - though this mock was more of a strawman for the big pieces, not a detailed interaction mock intended on conveying secondary layers of content (contextual, rich tooltips or slide out details sections)

> 3) Including individual tags is not what we discussed for v1, partly because
> it turns the app generator into an on-the-fly generator rather than being
> able to download pre-built packages. Also, I am not convinced picking
> individual tags will ever be what people want, since it's hard to know
> exactly which tags you will need down the road.
> 

Again, I agree, this was to be more of a strawman, I (or our UX person?...we have one, right?) will do a very detailed mock tomorrow/Friday

> I suggest a quick bulleted list with links to what's included in this (or
> every) template.
> 

Sure, a detailed interaction mock should, and will, include this.

> 4) Manifest builder is a good idea, but not for v1. This too will turn the
> app generator into an on-the-fly builder, while for now we should stick with
> pre-built zip files. Once we move past that stage, I think the manifest
> builder is great and might even be useful outside the app generator, so
> perhaps we should find a way to make it usable separately while allowing
> people to build a manifest in this context as well. For v1 though, let's cut
> this out.
> 

Agreed.

> Opinions?

Comment 21

[Fred Wenzel [:wenzel]]

(In reply to Daniel Buchner [:dbuc] from comment #20)
> > 1) The dropdown on top is overkill for the two types of apps ("generic app",
> > "game") that we have. I suggest we give people two pics to click on.
> 
> ...and Book/Magazine?

Is that a whole different app type, or just another layout under "generic app"?

> Again, I agree, this was to be more of a strawman, I (or our UX person?...we
> have one, right?) will do a very detailed mock tomorrow/Friday

Good -- for UX, need to reach out to Maria / Bram, but not sure what their schedules look like.

Comment 22

[Daniel Buchner [:dbuc]]

(In reply to Fred Wenzel [:wenzel] from comment #21)
> (In reply to Daniel Buchner [:dbuc] from comment #20)
> > > 1) The dropdown on top is overkill for the two types of apps ("generic app",
> > > "game") that we have. I suggest we give people two pics to click on.
> > 
> > ...and Book/Magazine?
> 
> Is that a whole different app type, or just another layout under "generic
> app"?
> 

It is a different layout type that will house book, magazine, and other permutations thereof. The general app layout was supposed to encompass the Flixter/Gmail/Github cases, where there are a few different general layouts that well service a variety of content - the layout types largely segment themselves if you ask yourself a question such as: "would book's presentational UX be well served by the same sort of layouts that Flixter/Gmail/Github uses?"

> > Again, I agree, this was to be more of a strawman, I (or our UX person?...we
> > have one, right?) will do a very detailed mock tomorrow/Friday
> 
> Good -- for UX, need to reach out to Maria / Bram, but not sure what their
> schedules look like.

I thought we were getting someone, are they planning on attending our Tuesday meetings?

Comment 23

[Daniel Buchner [:dbuc]]

Attachment: app generator with v1 scoping

Posted a new strawman mock scoped to v1 features

Comment 24

[Bram Pitoyo [:bram]]

Attachment: App Generator mockup (DRAFT 2)

Attached is the draft of the app generator that was build on Daniel’s idea, but with these improvements:

* Each layout has a title and a description, along with some space for us to list the best use for the layout (in addition to this, I recommend setting up a demo page) so developers know exactly what he’s getting when selecting a particular item.

* The title words ‘x-tags’, ‘modules’ and ‘libraries’ are links that lead to pages that will explain what they mean.

* Each x-tag, module and library has a link that opens the explanation page, as well as a demo. It’s very important to have a good set of documentation for all of these things.

* Mortar gets its own link, up above.

Otherwise this is a v1 implementation. The content is nowhere near final, and I’d love a list of contents that we will need to have on this page, so I know exactly what to design for.

Finally, I always aim to be very verbose with things, but let me know if the instructional design is too much hand-holding for our readers!

Comment 25

[Bram Pitoyo [:bram]]

Daniel, do you have a sample text that I can use to mock up one layout, as well as the list of layouts that we plan to have? I want to get an idea of how much space I will need to design for.

Comment 26

[Bram Pitoyo [:bram]]

After thinking about it some more, I think that we can merge the design of the app generator and reference apps pages together.

Start with what we have on attachment 676775 [details].

Then add:
– app selector, up top

Finally, remove:
– thumbnails
– web API usage
– custom element usage
– third-party libraries

Comment 27

[Bram Pitoyo [:bram]]

Attachment: App generator mockup (DRAFT 3)

This is the mockup of the app generator page made using assets found on Daniel’s reference app template (attachment 676775 [details]). We should integrate the design of these two pages together, because they’re functionally similar.

Comment 28

[Fred Wenzel [:wenzel]]

dbuc, what do you think? I like the simplicity of it.

Comment 29

[Daniel Buchner [:dbuc]]

This works for v1 with the following small reservations (mostly content based):

- I'd like to see a bullet list of all the key features of each layout under the short description

- Let's remove that top-level Mortar link right by the title, it seems out of place there

Comment 30

[Bram Pitoyo [:bram]]

Attachment: App generator mockup (DRAFT 4)

Comment 31

[Fred Wenzel [:wenzel]]

dbuc: Please comment/sign off, and if this is good to go, let's close this bug.

Thanks all!

Comment 32

[Fred Wenzel [:wenzel]]

Actually I have one more question, now that we removed a link to mortar altogether, I think we're making it unnecessarily hard for developers to find the source code to the templates.

The fact that this is open source and they can peruse the source code and file bugs etc. is a feature, not a side effect.

Should we link to it as a bullet point in the feature section perhaps?
"* powerful open web app template, [developed on github][link]"
or something like that?

Comment 33

[Daniel Buchner [:dbuc]]

(In reply to Fred Wenzel [:wenzel] from comment #32)
> Actually I have one more question, now that we removed a link to mortar
> altogether, I think we're making it unnecessarily hard for developers to
> find the source code to the templates.
> 
> The fact that this is open source and they can peruse the source code and
> file bugs etc. is a feature, not a side effect.
> 
> Should we link to it as a bullet point in the feature section perhaps?
> "* powerful open web app template, [developed on github][link]"
> or something like that?

We'll provide for Mortar with a section under the curated MDN Docs section. Each template should link to its Github repo, the link can go next to the title of the layout.

Comment 34

[Fred Wenzel [:wenzel]]

Sounds good, thanks.

Edna, I am closing this: You should be able to get started on the implementation bug 810979. There are some blanks to be filled in (like the precise wording and download URLs) but the structure is ready to go.

Comment 35

[Jen Fong-Adwent [:ednapiranha]]

Hey Bram, do you have graphics for the layouts in the mock? e.g. the columns (3 at the top, the large one on the side, etc)

Comment 36

[Bram Pitoyo [:bram]]

Hi Jen!

The graphic for the layouts are actually placeholders. I don’t know exactly how many layouts we will have (the last I heard was around 4?), and I don’t know what the layouts are called (one may be called “E-book” or something to that effect).

Daniel should know better, and be able to get you the names. After I get the names, I can go ahead and design icons for each.

Comment 37

[Fred Wenzel [:wenzel]]

(In reply to Bram Pitoyo [:bram] from comment #36)
> The graphic for the layouts are actually placeholders. I don’t know exactly
> how many layouts we will have (the last I heard was around 4?), and I don’t
> know what the layouts are called (one may be called “E-book” or something to
> that effect).

Yup we have 4, cf. my content etherpad in bug 810979. :)

> Daniel should know better, and be able to get you the names. After I get the
> names, I can go ahead and design icons for each.

Feel free to take a look at those and draft some icons for them. Let me know if you need any more info!

Comment 38

[Bram Pitoyo [:bram]]

Attachment: App generator layout icons

Per bug 810979 and this Etherpad: https://ecosystem.etherpad.mozilla.org/app-generator-content – I’ve generated two versions of layout icons.

1. List/Detail view
2. Tab view
3. Game stub
4. App stub

It’s styled with the same gradient that Marketplace uses site-wide.

Comment 39

[Bram Pitoyo [:bram]]

Attachment: App generator layout icons (PSD)

Comment 40

[Jen Fong-Adwent [:ednapiranha]]

Daniel or Bram, I will need the large image for the sections as per the mock.

These attached ones that Bram provided are just for the top icons, but I don't have any content for the left column beside the copy.

Comment 41

[Daniel Buchner [:dbuc]]

(In reply to Jen Fong-Adwent [:ednapiranha] from comment #40)
> Daniel or Bram, I will need the large image for the sections as per the mock.
> 
> These attached ones that Bram provided are just for the top icons, but I
> don't have any content for the left column beside the copy.

Bram, can you generate some cool wireframe/graphics for the actual layout mock that we'll show next to the text?

Edna, building off of the template names Bram generated, I would like to go with the following:

1. List/Detail
2. Tab Swipe
3. Basic Game
---
4. *Which template was this referring to again?*

Comment 42

[Fred Wenzel [:wenzel]]

(In reply to Daniel Buchner [:dbuc] from comment #41)
> 1. List/Detail
> 2. Tab Swipe
> 3. Basic Game
> ---
> 4. *Which template was this referring to again?*

Note that number 2 (Tab Swipe) does not exist yet for this iteration.

The number 4 you're missing is "App Stub" i.e., an "empty" HTML doc.

Comment 43

[Bram Pitoyo [:bram]]

(In reply to Daniel Buchner [:dbuc] from comment #41)
> Bram, can you generate some cool wireframe/graphics for the actual layout
> mock that we'll show next to the text?

Yes. I’ll do this. Thanks for assigning.

Comment 44

[Jen Fong-Adwent [:ednapiranha]]

Bram:

Any updates on the graphics for this?

Comment 45

[Bram Pitoyo [:bram]]

I’m working on this at the moment. Sorry for the delay.

Comment 46

[Bram Pitoyo [:bram]]

Attachment: list view icon - big

I use the same size that’s present on the sample app pages, which is 180x270.

Comment 47

[Bram Pitoyo [:bram]]

Attachment: tab view icon - big

Comment 48

[Bram Pitoyo [:bram]]

Attachment: game icon - big

Comment 49

[Bram Pitoyo [:bram]]

Attachment: app stub icon - big

Comment 50

[Jen Fong-Adwent [:ednapiranha]]

lol cats.

Comment 51

[Fred Wenzel [:wenzel]]

Can we close this bug? Looks like all design work is done for this iteration, right?