Script Only Stack Architecture

[Richard Gaskin]

Kay C Lan wrote:
> And now stepping on very thin ice I will go against the grain of 'User
> Notes' as previously implemented and currently re-suggested. Again, as
> an interim step I see them as very useful for capturing nuggets of
> information. The great thing about them is, as stated by Jacque, you
> don't need to learn any markup (or Git), and you can (could) do it
> immediately.
>
> IMO the ideal solution would be the Dictionary act like a Wiki Editor.
> Those with Contributor Accounts get Edit buttons in each of the
> relevant sections of each Dictionary entry. You want to add an
> excellent example, then you click the Example section Edit button and
> you add it right there, where it should be, and where it will be
> automatically colour coded; not at the bottom of a dozen other
> people's User Notes in lost black and white. You have a Warning,
> Caution or Tip that needs highlighting, then that is how it's
> presented; again not hidden amongst other User Notes in the same bland
> font. Also, a one line Example entry would be just that, a one line
> entry. The User Note format bloats it out with inclusion of who added
> it, and a time stamp and a couple of blank lines around the entry so a
> single line of relevance takes up 4 or 5 lines of Dictionary screen
> space. I personally don't need my name attached to every contribution
> I make - for those that do, maybe a list of Doc Contributor names in
> the About Livecode box similar to the list of names of LC Community
> contributors that currently appears.
>
> The Dictionary is really only a glorified Wiki. I suspect most people
> believe the success of Wikis is due to community contribution, but I
> believe just as important is Wikis FORCE a standard format and
> presentation, everything in it's right place, everything found where
> it should be. I think one of the problems Richard alludes to re bloat
> can be avoided if people are forced to think where exactly in the
> Dictionary entry structure does my nugget of information fit in and
> how do I word it so it does fit with the paragraph before and after.
> As a bonus, you can also quickly correct that minor spelling error in
> the preceding paragraph.
>
> The Dictionary is just another Livecode stack, so this is all possible
> with the talent and technology we have in front of us, the hardest
> thing to implement would be the Git integration so that each
> addition/amendment is vetted before inclusion with the next release
> and visible to the rest of us.
>
> Actually the biggest problem is who(s) is going to do build it. I
> believe the Team is still looking for a Community Docs advocate/leader
> to corral those with such inclinations and ideas. The reality is the
> former idea of User Notes is probably a lot easier/quicker to
> implement than turning the Dictionary into an .lcdoc Editor/Git
> Integrator.
>
> I should probably keep my big mouth shut from now on as the ice has
> surely broken and I'm in very deep water.

Au contraire.  I've quoted the meat of that post intact, long as it is, 
because I feel it merits a second read.  It's a very good collection of 
ideas which, if implemented, could greatly streamline community 
contributions to the Dictionary.

And like the rest of the clarity expressed there, you hit the hardest 
part spot-on:

    Actually the biggest problem is who(s) is going to do build it.

A project of this scope would be a considerable undertaking.  The team 
could do it, but it would need to go into queue after the current 
objectives and the rest of the Kickstarter goals, so let's politely just 
file that notion under "Not Soon". :)

The community could do it, but finding the intersection of interest, 
skill, and available time would be at best very difficult.  It's not 
like one of the joyous one-offs we toss together, like Richmond's IDE 
mods or my 20-line script that makes revMenubar look more Ubuntu-like. 
This is a big task, big enough to warrant a team and a Gantt chart.

Conceiving such a system is brilliant but takes only a few minutes to 
draft an outline like the one above.  Drafting a functional spec and 
workplan would take much more time, and coding it, testing it, and 
building maintenance systems for it would be a pretty hefty commitment.

All of it is indeed very achievable in LiveCode.  The project I work on 
for emergency medicine is similar in scope, and all of it -- from the 
client to the server all the way down to the data store and Web 
publishing subsystem -- was built entirely in LiveCode.  But it was 
funded by a fairly large company with a clear upside for the investment.

Here the ROI is arguably strong but not quite as strong, when we 
consider that Github's Markdown is fairly easy to learn and can be used 
gracefully in any text editor, even their online form.

So I like the idea.  Very much.  And if we can get resources who could 
commit to seeing it through I'd love to work with it.  But the ROI may 
be difficult to justify, as it would require a lot of people's time away 
from other activities.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com