746817 - Warn demo authors when they use obsolete (or soon-to-be-obsolete) technologies

Status: RESOLVED WONTFIX

(developer.mozilla.org Graveyard :: Demo Studio / Dev Derby, enhancement)

Comment 1

[John Karahalis [:openjck]]

What problems would this solve?
===============================
Some of the demos on the Demo Studio use technologies that become obsolete over time. Vendor prefixes are a good example of this, but there are many others. These technologies work fine as temporary solutions, but over time the demo may stop working as the technologies become obsolete.

Who would use this?
===================
This should happen automatically. The Demo Studio should automatically notice when a demo is using obsolete (or soon-to-be-obsolete) technologies.

What would users see?
=====================
Two options:

* Obsolete: If the Demo Studio detects that a demo is using an obsolete technology (for example, vendor prefixed CSS properties when un-prefixed versions are already available), the Demo Studio should encourage the author to update his demo immediately.
* Soon-to-be-obsolete: If the Demo Studio detects that a demo is using a technology that will be obsolete soon (for example, vendor-prefixed CSS properties when no other options are available), the Demo Studio should warn the author that the demo might require an update at some point in the future. Maybe the Demo Studio could even give the author an estimate of when the demo will need an upgrade ("This feature will be unsupported in Firefox 20, which will be released in two months") or email the author when the technology officially becomes obsolete.

What would users do? What would happen as a result?
===================================================
Authors would see these warnings and update the demo accordingly.

Is there anything else we should know?
======================================

Comment 2

[Les Orchard [:lorchard]]

FWIW, "technology detection" sounds like a pretty big dev challenge. Do you have any pointers to prior art, or some place else that already does something like this?

Comment 3

[John Karahalis [:openjck]]

Just thinking of it from a point of view of user experience. Flagging entries would work, but having this information detected automatically would be preferable. If it would be a huge technical hurdle, we can of course look into other design solutions.

Comment 4

[Les Orchard [:lorchard]]

(In reply to John Karahalis [:openjck] from comment #3)
> Just thinking of it from a point of view of user experience. Flagging
> entries would work, but having this information detected automatically would
> be preferable. If it would be a huge technical hurdle, we can of course look
> into other design solutions.

Well, I can imagine many users would like unicorns. :) But yes, that's what I'm saying - it would be a huge technical hurdle.

Comment 5

[Les Orchard [:lorchard]]

To elaborate: What might help is to have an inventory of technologies. The means of detecting each one would most likely be hand-tweaked on a case-by-case basis.

Some might be easier to detect than others with simple text matching. ie. does a CSS transition show up somewhere in .css? Is it actually used, and not just cruft from Bootstrap or suchlike? 

Others might be very hard to detect definitively without doing active code tracing - something with which I'm unfamiliar. ie. does the demo try to use Web SQL in JS, or is there just an unused reference to it somewhere in a framework lib?

And, overall, would chasing down this dev effort be worth it vs just asking authors to self-describe the technologies they used with tags at submission time?

Comment 6

[John Karahalis [:openjck]]

(In reply to Les Orchard [:lorchard] from comment #4)
> (In reply to John Karahalis [:openjck] from comment #3)
> > Just thinking of it from a point of view of user experience. Flagging
> > entries would work, but having this information detected automatically would
> > be preferable. If it would be a huge technical hurdle, we can of course look
> > into other design solutions.
> 
> Well, I can imagine many users would like unicorns. :) But yes, that's what
> I'm saying - it would be a huge technical hurdle.

I agree. The specification (comment 0) is just a request. What /should be/ done depends on a combination of the design that results from that request and the technical constraints that limit it.

> And, overall, would chasing down this dev effort be worth it vs just asking
> authors to self-describe the technologies they used with tags at submission
> time?

Given your explanation of how hard this would be, no. Self-describing sounds good like a good alternative. Thanks for the insight.

No on how we could highlight the documentation. I still like the idea of a "How this demo was made" box, with links to some beginner information (/learn, etc.) as well as documentation for each of the technologies used. Unfortunately, specing this (or some other idea) out completely requires more design resources than we have right now. Cool if I move this back into the "Selected" backlog?

Comment 7

[David Walsh :davidwalsh]

Is it feasible for us to moderate demo submissions if it's really important?  Detection will be extremely hard (it's almost like detecting good code), and devs have no reason to upload bricked demos.  I guess I don't know that this is something we should really tackle as a priority, especially considering users can flag bad demos.

Comment 8

[John Karahalis [:openjck]]

Agreed that this is not a priority. Still a worthwhile problem to solve at some point, as I hear people running into this every now and then, but not the most important thing we could be doing right now.

I am happy to table this for now. No priority is set, so it will not be on our immediate radar any time soon.

Comment 9

[Justin Crawford [:hoosteeno] [:jcrawford]]

Is there any evidence that this problem is significant enough to devote any more discussion to it? Or can we WONTFIX this as a good idea whose time will probably never come?

Comment 10

[John Karahalis [:openjck]]

(In reply to Justin Crawford [:hoosteeno] [:jcrawford] from comment #9)
> Is there any evidence that this problem is significant enough to devote any
> more discussion to it?

Nope.

> Or can we WONTFIX this as a good idea whose time will probably never come?

Definitely. Nice idea, but not likely to ever happen with our resources.

:-)