Rename 'interactive widgets' to 'interactions'.

[GoogleCodeExporter]

What steps will reproduce the problem?

This is a code health issue.

Currently, we have an extension type called 'widgets', which subdivides further 
into the categories of 'noninteractive widgets' and 'interactive widgets'. 
We're also thinking of introducing exploration-scoped objects, currently called 
'gadgets'. These names are terrible, because they don't convey meaning.

Experience has shown that a much better name for the latter is 'interactions', 
so the main focus of this issue is to pull out 'interactive widgets' into a 
separate extensions/interactions folder. It would also be nice to do something 
similar for 'noninteractive widgets' (possibly extensions/rte, since what they 
really are is extensions to the rich-text editor).

Original issue reported on code.google.com by s...@google.com on 9 Jan 2015 at 6:30

[GoogleCodeExporter]

This is an excellent idea. If you're going with the 'extensions' theme you 
could call gadgets extensions/exploration.

A few suggestions:
 - Grep the codebase for all occurances of 'widget' and change where appropriate.
 - Same for the wiki.
 - For protractor you're going to have to fix all of the require() links into and out of the extensions directory.
 - If possible it would be nice to schedule and announce this code change some time in advance and then do it fast, since it's going to be pretty disruptive to everyone working on extensions who then tries to merge in old branches.

Original comment by jacobdav...@gmail.com on 12 Jan 2015 at 5:10

[GoogleCodeExporter]

Thanks, Jacob!

Telling interaction creators about the imminent changes is an excellent idea. 
I've added Zhan Xiong, Kevin and Ashvin to this thread so they can follow along.

Not sure about extensions/exploration -- the other types of extensions 
(interactions, rules etc.) are also extensions to an exploration. Michael 
suggested extensions/panels; what do you think?

Original comment by s...@seanlip.org on 12 Jan 2015 at 5:33

[GoogleCodeExporter]

Good point. Are 'gadgets' going to live exclusively in panels?

Original comment by jacobdav...@gmail.com on 12 Jan 2015 at 9:06

[GoogleCodeExporter]

Thinking of implementing the past 'gadgets' idea under the name 'panels'. We're 
not 100% set on the name, but confirming it will likely be housed exclusively 
at extensions/panels if that's the name we choose.

Original comment by anu...@google.com on 13 Jan 2015 at 12:39

[GoogleCodeExporter]

Hi Michael,

Amit just made a suggestion, which I find quite appealing: instead of just a 
catch-all 'gadgets'/'panels' name for everything that's exploration-scoped, 
what do you think about splitting it into several extension categories, e.g.:
  - meters (progress bar, score bar)
  - tools (coding playground, calculator)

and so on? Each of these could then go in a specific place in the UI.

Original comment by s...@seanlip.org on 13 Jan 2015 at 2:44

[GoogleCodeExporter]

Interesting idea. Not opposed to it, but not sure I'm clear on the difference.  
As it is, extensions/interactions/ will have sub-folders for /LogicProof 
/GraphInput /TextInput, but the containing /interactions/ directory helps 
understand the structure & development of those modules via this documentation: 
 https://code.google.com/p/oppia/wiki/CreatingExtensions

Whatever we call gadgets/panels, it seems there will be a benefit to choosing a 
containing framework for "custom interactions / visuals / logic that persist 
across all states".  I honestly don't have a good enough feel for what all the 
'gadgets/panels' are users might want to create, so it's hard to say how much 
directory crowding we might see bring them up a level.

Original comment by anu...@google.com on 13 Jan 2015 at 8:30

[GoogleCodeExporter]

Original comment by s...@seanlip.org on 14 Jan 2015 at 5:27

[GoogleCodeExporter]

OK, let's KIV the discussion on gadgets -- this will probably become clearer as 
Michael and I work on a design doc, and develop a better understanding of the 
space.

I have completed the widgets migration in this branch over the course of five 
monster commits:

    https://code.google.com/p/oppia/source/list?name=rename-widgets

After some thought, I think I'm going to merge this to develop now to prevent 
further skew. Unfortunately this is going to slightly disrupt work on the 
multiple-choice-grid branch (Kevin's) and the chess branch (Ashvin's). However, 
Kevin's changes are small, so -- Kevin, would you mind starting a brand-new 
branch from 'develop', replicating your changes on it, and deleting 
multiple-choice-grid?

As for the chess branch, it actually seems like a fairly straightforward 
migration to copy the current extensions/widgets/interactive/ChessInput 
directory and stick it in its new location 
(extensions/interactions/ChessInput), though I'm also noticing some changes to 
other files like extensions/rules, extensions/objects and core/templates that 
need to be replicated. Ashvin, would you mind either starting a brand-new 
branch from 'develop' and migrating your changes there too, or merging the 
latest version of 'develop' into your branch at the earliest opportunity (after 
I've checked in the widgets updates)?

Thanks, and sorry for the inconvenience!

Original comment by s...@seanlip.org on 15 Jan 2015 at 12:55

[GoogleCodeExporter]

Thanks for the update! Not a problem! 

Original comment by kevinlee...@gmail.com on 15 Jan 2015 at 1:00

[GoogleCodeExporter]

OK, I've pushed the commit to develop. Not closing this issue yet, since I 
still need to:

- migrate demo explorations to new format
- update wiki docs

I'm going to be away until Tuesday, but will try and get back to this when I 
return. In the meantime please feel free to make branches off of 'develop'!

Also, if you run into any issues with your dev server after syncing to HEAD, 
try going to the admin page localhost:8000 and flushing memcache. Some old 
domain objects might have been cached.

Original comment by s...@seanlip.org on 15 Jan 2015 at 5:08

[GoogleCodeExporter]

Documentation (finally) updated. Decided to leave the demo explorations as they 
are, since they are already auto-converted to the latest schema version on load.

Marking this issue as fixed.

Original comment by s...@seanlip.org on 26 Apr 2015 at 2:13

• Changed state: Fixed