Closed Bug 863359 Opened 11 years ago Closed 11 years ago

Determine Make Schema required fields.

Categories

(Webmaker Graveyard :: MakeAPI, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: thecount, Assigned: thecount)

References

Details

(Whiteboard: u=dev c=makeAPI p=1 s=2013w17)

Attachments

(1 file)

Right now I am attempting to use this with Thimble, to create a new make.

All I care about right now is url and the user's email. I think we can get away with making anything else we have at this point to be optional, and can be updated later.

id is generated so it's also optional.

Url and email might be pretty heavy handed as the only required properties, though, so I am cool with meeting in the middle if others have other requirements.
Blocks: 861816
I'm going to picky back this and also discuss some of the fields we have in there right now.

url - required

author - required (assuming it stays as storing the email. See bug 863403. I'm thinking we should require an email but separate it out into it's own field but not something given back when the make api has information queried against it)

description/body - Shouldn't by required

locale - not required ( defaults to en_us )

title - not required ( should have default )

difficulty - not required ( should default to Beginner )

goal - not required. I personally don't see the point of this field.

thumbnail - not required ( applications can handle their own default )

publish - not required. Also not seeing the need for this information to be stored.

remixedFrom - not required. Is this field too popcorn specific?

createdAt - required.

updatedAt - Once updated, required.

deletedAt - Once deleted, required.

These are my thoughts. Throwing around for some info/feedback.
Flags: needinfo?(david.humphrey)
(In reply to Matthew Schranz [:mjschranz] from comment #1)
> I'm going to picky back this and also discuss some of the fields we have in
> there right now.

Might be worth splitting this off into a separate bug, and just doing the bit that Scott needs vs. solving all the problems in one go.

That said, some comments below

> 
> url - required
> 
> author - required (assuming it stays as storing the email. See bug 863403.
> I'm thinking we should require an email but separate it out into it's own
> field but not something given back when the make api has information queried
> against it)
> 
> description/body - Shouldn't by required

It would be good to talk to Kate/Cassie (CC'ed) about the requirements of the top-level UI that's consuming this.  We might actually need a description per project?

> locale - not required ( defaults to en_us )
> 
> title - not required ( should have default )

Again, this might break UI expectations.

> difficulty - not required ( should default to Beginner )

Do we really need this?  Is it something we could do with a tag?

> goal - not required. I personally don't see the point of this field.

Agreed.  I don't think we want to keep any fields we don't plan to use.  Let's add them when we need them vs. leaving them in because Simon had them once upon a time.

> 
> thumbnail - not required ( applications can handle their own default )

Is this true?  Do we always want a visual thumbnail for a project in the Make API?  Throwing to UI folks for thoughts.

> publish - not required. Also not seeing the need for this information to be
> stored.

Probably we can yank this?

> remixedFrom - not required. Is this field too popcorn specific?

Thimble is moving to remixedFrom too, so we'll want it.  We might want this to be a URL though.
Flags: needinfo?(david.humphrey)
Blocks: 863873
Sorry for the long winded comment, but there is a lot on my mind for this particular area.

(In reply to David Humphrey (:humph) from comment #2)
> (In reply to Matthew Schranz [:mjschranz] from comment #1)
> > I'm going to picky back this and also discuss some of the fields we have in
> > there right now.
> 
> Might be worth splitting this off into a separate bug, and just doing the
> bit that Scott needs vs. solving all the problems in one go.
> 

Agreed, faster we get this what I need, the faster we can find new problems.
I'm up for taking this and prototyping something.

> That said, some comments below
> 
> > 
> > url - required
> > 
> > author - required (assuming it stays as storing the email. See bug 863403.
> > I'm thinking we should require an email but separate it out into it's own
> > field but not something given back when the make api has information queried
> > against it)
> > 
> > description/body - Shouldn't by required
> 
> It would be good to talk to Kate/Cassie (CC'ed) about the requirements of
> the top-level UI that's consuming this.  We might actually need a
> description per project?

Could this be something the displaying app can default based on the content type(thimble popcorn)? Either way, it should default and not be required at some point, either in the api or in the consuming app.

> 
> > locale - not required ( defaults to en_us )
> > 
> > title - not required ( should have default )
> 
> Again, this might break UI expectations.

Do we have a way to reliably get this programmatically?

> 
> > difficulty - not required ( should default to Beginner )
> 
> Do we really need this?  Is it something we could do with a tag?
> 

I would love to do away with this and make it a tag.

> > goal - not required. I personally don't see the point of this field.
> 
> Agreed.  I don't think we want to keep any fields we don't plan to use. 
> Let's add them when we need them vs. leaving them in because Simon had them
> once upon a time.
> 

If we need it at some point, we can add it via a tag, but I also think we don't need it atm.

> > 
> > thumbnail - not required ( applications can handle their own default )
> 
> Is this true?  Do we always want a visual thumbnail for a project in the
> Make API?  Throwing to UI folks for thoughts.
> 

I agree with Matt here, we should let the apps default this. Example, the primary gallery could check if the project is thimble, to load up a thimble default that makes sense to the size requirements of that gallery.

> > publish - not required. Also not seeing the need for this information to be
> > stored.
> 
> Probably we can yank this?

I am all for yanking things. I am actually having a hard time remembering what this was for.
> 
> > remixedFrom - not required. Is this field too popcorn specific?
> 
> Thimble is moving to remixedFrom too, so we'll want it.  We might want this
> to be a URL though.

This is def something we can fill in, but also is not required. Is it safe to assume that if it is empty, it means it is an original project?

Yes, both Thimble and Popcorn maker do this.

We should be careful to not assume our apps for any of these. We can fill them in and default/require them as it makes sense to the app, but if we want others to be filling and consuming this API, we should keep open and dynamic in mind for this. Tags are useful for this.

Also, we should consider not storing user or author on the specific project data, instead store the email and use that to link to a profile entry somewhere, that way if a user updates their name or info in the profile, we can then update any displayed projects to now display updated author info. Is this something that the login module can store?
Assignee: nobody → scott
Attachment #740309 - Flags: review?(schranz.m)
Comment on attachment 740309 [details]
https://github.com/mozilla/MakeAPI/pull/23

I'm having troubles agreeing on some of these fields being required vs not required and have somewhat changed my thought behind why some should be or not. Mostly due to the UI considerations Dave brought up.

I'm going to CC Kate on this to get some opinion.
Attachment #740309 - Flags: review?(schranz.m)
Attachment #740309 - Flags: review-
Attachment #740309 - Flags: feedback?(kate)
Whiteboard: u=dev c=makeAPI p=1 s=2013w17
Summary: Create make required fields → Determine Make Schema required fields.
Some updates.
Attachment #740309 - Flags: review- → review?(schranz.m)
Comment on attachment 740309 [details]
https://github.com/mozilla/MakeAPI/pull/23

Land this.
Attachment #740309 - Flags: review?(schranz.m)
Attachment #740309 - Flags: review+
Attachment #740309 - Flags: feedback?(kate)
Just wanted to throw in that I have been following along with the conversation. It might be tricky to figure out what elements exactly we will want in the final UI at this point, but hopefully if it starts to look overwhelming we can pare it down once we see it on the page. This is a great start and really useful.

I do think we may want to require the user to input title, and maybe difficulty too. Those in my mind are the two most important elements (+URL) from the perspective of someone searching for something to learn. We also want to make sure that as the number of makes grow, a user's search can pick up results that are precise and relevant, so seems it would definitely help to keep each make as descriptive and as user-generated as possible. This is maybe an argument for keeping remixed-from as well (as preferably an auto-populated field?).

I agree on the other fields, thumbnail, description, locale, publish, goal - shouldn't be required. This is all from UX/UI perspective so of course do what you gotta do on the backend.
Staged: https://github.com/mozilla/MakeAPI/commit/1e0480e3d4b5eab4fe44bb05c77346897544b9e2
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: