Better demos

[scottgonzalez]

(ported from planning wiki)

General Ideas/Requirements

• We need to be able to update demos independent of the code. Currently we have to make a new regular release in order to update demos on the website. That sucks. Based on that we should consider moving demos into the site repo.
• It would be interesting to make demo code interactive. That could happen by integrating jsbin (a link that opens the demo on a new jsbin, ready to run and edit). Or we could make the source section editable, using codemirror.
• Once we have demos that touch multiple widgets, there should be a way to filter demos to show those where a single widget is used. For example selecting "slider" and "accordion" would show only those demos that feature both those widgets.
• Demos should be editable, avoiding the need to manually copy the code. This could be integrated with jsbin.com, where a bin is automatically created using the code of the demo.

Individual widgets

Currently our demos mostly consist of show casing each individual option. That should be part of the API documentation (if necessary at all), while demo show actual examples - something a developer would use in a site or application.

Kendo UI does a pretty good job with their demos, we should take some inspiration there.

Composite demos

We need a few composite demos, that show a combination of widgets in a real-world scenario.

Scenarios include:

• Booking a flight online would be a great demo for jQuery UI, featuring both autocomplete (eventually selectmenu) and datepicker at their best.
  • A good reference: https://wizzair.com/en-GB/Search - note how it assumes One Way until you choose a return date, with a customized jQuery UI datepicker pointing that out.
• [others]

Composite Demo Sample:

• Online Flight Booker: Repo - Demo Page

jsbin.com integration

Mentioned above already, here's some more details:

• When jqueryui.com is deployed, it would create bins for all demos, preferably using an official API (not available, yet)
• Each demo then has a link to jsbin, something like a "Edit on jsbin" button, that opens the already existing bin.
• Once the user starts editing that bin, a unique clone is created, so that they have their own copy.

[jzaefferer]

Not that important right now, but after reading this, I wanted to share some thoughts:

We need to be able to update demos independent of the code. Currently we have to make a new regular release in order to update demos on the website. That sucks. Based on that we should consider moving demos into the site repo.

At the same time, we use demos for testing widgets, and as long as deploying this site is such a PITA, it would just get worse. Since we don't have that many demo issues that we need to deploy asap. Maybe we can do a demo hotfix branch which gets pulled only for deploying updated demos.

[lucklypriyansh-2]

Well we could also use small gif to illustrate the effects of code .In Lots of case i have seen people copy the code and paste it just balantly and tried to run it without knowing whats actually happening beneath the code .If we could some how tell them just some of the basic underground function of code then it will drastically reduce the effort time for other developers to understand it .

[kumarrishav]

@scottgonzalez @arschmitz I found this issue on GSOC 15 project list and got interested to work on this as gsoc project. But before that i want to dive into the code. After reading the issue in detail, what i got is, to implement a better demo system of widget and include somethings like jsbin where user can edit the widget code on the fly.

[Chandrakant4993]

I found this issue on GSOC 15 project list and got interested to work on this as gsoc project

[jzaefferer]

Please note that we already have several students interested in this project, including finished proposals. I highly recommend looking at some of the other ideas that are less congested. Also, its time for proposals.

[jzaefferer]

Regarding the jsbin integration: The rought idea here is to have a "Edit on jsbin" button that creates a bin on the fly, with the content of the demo, ready to run and edited. Its currently unclear how that would actually work. There are jsbin pro accounts that have additional features, that might help. @arschmitz has been talking to Remy about that, but we have no clear way forward, yet.

We definitely don't want to maintain hundreds of jsbin's by hand, so we need some kind of automated solution. Maybe we need to contribute to jsbin itself to help build an API for importing code. Or hack something together that opens a page at jsbin.com and pastes into the various input fields.

[arschmitz]

@jzaefferer the second solution has been done by @gnarf already, but I think if we can get the api integration going, that would really be preferable. The advantage of api integration would be the bin url would not change on every update. I'm going to try to reach out to @remy again today on this.

[jzaefferer]

The advantage of api integration would be the bin url would not change on every update.

That sounds different from what I had in mind. In my model, no jsbin is created until a user clicks on "edit on jsbin". Can you outline what model you're working with?

[arschmitz]

@jzaefferer the bins would be created when the website is deployed, somewhat similar to what we have now. It would just add a step to create the bin. Then when the user clicks the banner to edit, it would just go to the already created bin. Don't want to create a new bin on every click that seems excessive. Then if / when the person edits it will automatically create their own copy.

[jzaefferer]

Gotcha, that way we could also embed the bin on our site.

[arschmitz]

@jzaefferer last time we talked about this there were concerns about just using an embed, since it would rely on jsbin availability, for the websites to work. So we were going to still embed something like we have now from a local page, and then just have an edit banner to go to the bin.

[jzaefferer]

I've talked to the author of jsbin-sync over the weekend. This looks like we could integrate it into our deploy of jqueryui.com (and the api site), similar to what we've discussed in this ticket. Its still unclear how we could deal with versioning major release (1.12, 1.13, and so on), but @rodneyrehm has been talking to Remy about that.

Even without that in place, we should test the tool to see how far it can get us already.

@arschmitz unless you've got something working elsewhere, I'd try jsbin-sync in the next few days.

[Mottie]

Alternatively, JSFiddle has built-in integration with GitHub repositories and Gists.

[PapillonUK]

I think the demo for the Widget factory could definitely do with a re-write. The Widget factory is one of the most powerful components of jQueryUI but at the moment you have to Google around or buy a good old paper book to discover its power! The current demo doesn't do it justice.

[scottgonzalez]

That alone isn't very useful. I'm also not sure how you'd find out the power of the widget factory from a demo as opposed to articles, tutorials, and documentation. Do you have concepts for a demo in mind that would be valuable?

[PapillonUK]

Hi Scott,

I agree, obviously a demo isn't enough to show all the features of the widget factory, but I think it could give a clearer idea of what the factory can be used for and perhaps lure people to reading more about it. I think there could be two demo's - one showing how easy it is to inherit from one of the other jQueryUI widgets - perhaps a confirmation dialog that extends the dialog control with a simple "OK" button. That would be about 10 lines of code. And another, slightly more advanced demo such as the one for pop-up notifications in TJ VanToll's "jQueryUI in Action" book (p308). Although the current demo is good, I don't think it's showing something of such immediate practical use.
I think it needs clarifying how easy the jQueryUI widget factory makes it to tweak the behavior of the standard controls so you get exactly what you need.

[determin1st]

let's make jQueryUI great again 8)

[varunnayyar76]

aaaa