AsciiArtGuiShorthand is one possible solution to the GuiShorthand problem.

The context and forces for this ProtoPattern are on the GuiShorthand page.

[RefactorMe:  If you have a better name for this ProtoPattern, please rename this page.]

----
'''Possible Solution''':

[What would the GuiShorthand notation to tell someone how to add a graph to this Wiki page look like?]

''Here is one possibility. It's a little clumsy because a text area is a little different paradigm than a GUI:''

 [Edit Text]
 -- type the address of the graph url into the text field below at the place you want it --
 |Wiki Page Title
 |  +-----------------------------------+
 |  |					|
 |  |_http://<url''''''address''''''of''''''graph''''''picture>_|
 |  |					|
 |  +-----------------------------------+
 |__[Save]
 [<-Back]
 [<-Back]
 [F5]

 |	  -- multiline page
 |__	-- end of multiline page
	+-----	-- text input area
	|	

----
'''Resulting Context'''

This AsciiArtGuiShorthand proposal is very ambitious.  It tries to show pictures of text boxes and command buttons, using a very brief syntax.  
	1. Unfortunately, the [] syntax for showing command buttons can be confusing, especially if the command button text has an arrow on it.  
	1. The text box pictures are almost as big as a screenshot, and even more confusing.

------------
'''Other Suggestions'''

  [foo |v]		// Drop-down list ("v" is down-arrow)
  Name: [	]	// Prompt with text-box
  Name: [______]	// Alternative prompt with text box
  Name: ______          // Alternative 3: Maybe brackets are unhelpful?
  Name: |_____|         // Another alternative
  A (_) B (*) C (_)  // Radio button with "B" selected
  A [_] B [X] C [X]  // Check-boxes (risk of mistaking for 1-char text-box small IMO) ''It *is* a 1 char text box. Use X instead of * to further distinguish from radio buttons.''
  (*Button*)

--------
''Version "Martha"''

I've been thinking about an "executable" version of this more, sort of a "gui wiki" markup language, and here is my latest incarnation:

  // short version
  Textbox:  [t|1	]
  checkbox: [c|2]
  radio buttons:  X [r|3] Y [r|3] Z [r|3]
  drop down list: [d|4	]
  text area: [a|5	]
  button:	[b|6	]
  @@
  2: default=off
  5: rows=7 foo=bar
  6: text="Push Me"

Square brackets show where the widget goes. The "@@" separates the "visual layout" area from the specification area of the text file. This separation allows one to put a lot more optional detail about a widget without having to embed that detail into the WYSIWYG Ascii-art part. The first parameter in square brackets is the widget type indicator, and the second is the reference name, which can be a number or alpha-numeric (but no funny punctuation or spacing). Here is an alternative using verbose names and more parameters:

  // verbose version
  Textbox:  [textbox|one]
  checkbox: [checkbox|two]
  radio button:  X [radio|three|1] Y [radio|three|2] Z [radio|three|3]
  drop down list: [dropdown|four]
  text area: [area|five]
  button:	[button|six|"Push Me"]
  @@
  window_title: text="My Example"	// reserved name for window title
  two: default=off
  five: rows=7 foo=bar

The reason for the "shortcut" version is that smaller widgets, such as check-boxes need to take up as little space as possible if we want the square-bracket spacing to mean anything (which we do if we want WYSIWYG with fixed pitch). Also note how the radio buttons have 3 parameters. The optional 3rd parameter allows us to know which one was selected (radio-boxes need this because the options are mutually exclusive within a named-group). If the 3rd parameter is not given, then the resulting value is based on the occurance ordering in the file (1,2,3,etc.). The short and long format are not assumed to be mutually exclusive. In case you really need to squeaze space, perhaps this should also be allowed:

  radio button:  X [|3] Y [|3] Z [|3]
  (etc...)
  @@
  3: type=radio
  (etc...)
	
The problem is that there is no way to have it short and also specify the sub-values of radio-buttons. Instead, perhaps we can add a dollar-sign-based substitution convention:

  radio button:  X [$7] Y [$8] Z [$9]
  (etc...)
  @@
  $7: replace="r|three|1"
  $8: replace="r|three|2"
  $9: replace="r|three|3"
  (etc...)

Or, we could just make the widget reference name come before the widget type indicator and then use a "type=" clause in the specification section. But, I think it is more readable with the widget type coming first. This means that a widget definition only needs a name at minimum, nothing else. (The rest is specified in the Specification section.) However, radio-button grouping needs to be reworked. Radio-buttons seem out to kick simplicity in the gonads no matter what we do. Maybe just tell people to use drop-down lists instead if there is more than one radio group. This is supposed to be KISS-Wiki-like, not Have It Your Way. Needs some deep thinking...

The text-area also has some sticky issues because it is hard to represent multiple rows with ASCII-art. Thus, the number of rows needs to be explicitly specified.

  
----
'''Discussion'''

''it's like http://web.mit.edu/macdev/asciiMac/''

RefactorMe:  
* If you think this is the best solution among ProgrammersGuiShorthand, AsciiArtGuiShorthand, and SanguineGuiShorthand, you may want to reincorporate this page into the GuiShorthand page.
* If you have a better name for this ProtoPattern, please rename this page.
* I think we need to distinquish between "executable" intended markups and documentation-only markups.
----
See also:  GuiShorthand, ProgrammersGuiShorthand, SanguineGuiShorthand, AsciiGuiGeneration, CategoryText