Aug 252018
 

The following best practices for creating and publishing graphics are application-agnostic and can be done in everything from open source software to top-flight, tools-integrated component content management systems. They work in nearly every common output media; and exceptions are noted when they apply. I employ Microsoft ® Windows® OS terminology and keyboard shortcuts, but nearly every other OS has similar shortcuts or tools that accomplish the same effects.

Capturing screen shots

  • Ensure that you are using a ‘classic’ desktop theme with no gradients, glass effects, or other uncompressible effects applied to the window chrome (title bar, borders, scroll bars, title bar buttons).
  • Set your desktop resolution to the highest it can support for ‘version 1’ of the application; and note that resolution so that you can return to it in later versions.
  • Do not use font scaling.
  • If manually configurable, use font smoothing (almost always enabled automatically, in modern OSs).

This approach ensures that your files will compress efficiently and remain consistent year after year, so that you can update screens selectively instead of in toto.

  • For native applications, use Alt+Print Screen to capture only the active dialog.
  • For web-based applications, use a capture application that allows you to capture only the browser viewport.

Both of these methods eliminate the need to carefully crop to pixel precision in your raster-art image-manipulation program.

  • If you must manually crop, do so to a hard, visible edge whenever possible (rather than a whitespace edge).
  • Avoid using ‘tear’ or ‘fade out’ effects when you must crop to whitespace, because they are hard to consistently apply and they greatly increase final file size. Instead, draw a hard, solid line for it in your image manipulation program; and note the line color and weight for later.

Creating line art

  • No matter what vector-art application you use to generate line art (Inkscape, Microsoft Visio®, LibreOffice Draw), shrink your canvas to the drawing contents prior to saving.
  • Save line art as either SVG or PDF.
    • Exception: If you are generating compiled HTML Help, you must export as raster art. If so, rasterize it to 96 dpi (common screen resolution) to avoid scaling issue in the HTML. In that case, save it to PNG.
  • Always save the typeset file using the same file name as the image-manipulation application’s source file name. If necessary, append a suffix to the source and typeset file names to distinguish them, though if you follow the above best practices, the file extension will also distinguish them and make a suffix redundant.

Applying callouts to captured images or line art

  • Create a library of callout objects in your vector-art application.
  • Always use line art and text (which is itself vector art) to make callouts.
  • Gradient and shadow effects might or might not affect final file size, depending on your vector-art image manipulation application. Use at your own risk. Do not use shadows unless the callouts overlap the image.
  • If you are using overlapping callout and lines, use colors that will consistently contrast with the bulk of the application’s colors. Otherwise, you are almost guaranteed to end up needing to use shadow effects or contrast-increasing callout borders (line around line, container or line around text)
  • Do not use words as callouts:
    • Use alphabetic callouts for pointing out image elements that you intend to define in typeset text below the typeset image.
    • Use numeric callouts for enumerating sequences; and if you use a containing shape, make it a different one than the containing shape for defining callouts. Either set these numerals to the step numbers of the task that will refer to them; or use a different type of numeral system (for example, Roman numerals or Greek alphabet) and set them sequentially.
  • Keep those object in linked layers so that you can easily copy all of their layers, paste them into new layers, and edit the text component of the callout.
    • Exception: If you elect to use only text for callouts, without surrounding circles, squares, shadows, or other offsetting effects, then you will not need more than one text layer and, as such, nothing else linked to it.
  • If you intend to have callouts off to the side of the image rather than completely overtop of the image, you have two options, each with its own consequences:
    1. All side callouts must be on the right side of all images, which can quickly become constraining.
    2. Side callouts require additional attention to detail or a typesetting concession:
      • The leftmost edge of left-side callouts must always be an exact distance from the left edge of the image.
      • You must commit to always centering the image when it is typeset.

      Failure to apply one of these two approaches will lead to the effect of your images seeming to ‘randomly’ slide left and right relative to the page margins.

Saving raster-art images without callouts

  • Always save as PNG.
    • Exception: If an output format does not support PNG… first consider going to a different output format; but if not, then save as 100% quality JPG. If you want a smaller file size in final output, post-processing the output file is a better way to compress than ‘ruining’ your source format right out of the gate.
  • Always save the typeset file using the same file name as the image-manipulation application’s source file name. If necessary, append a suffix to the source and typeset file names to distinguish them, though if you follow the above best practices, the file extension will also distinguish them and make a suffix redundant.

Saving raster-art images with callouts

  • See “Creating line art” above, so that the callouts remain vector art (and both SVG and PDF support embedded raster art).
Apr 232018
 

Proposal: New internet protocol I’d call “socnet”.

  • Similar to RSS, it’s a subscription protocol delivering data via XML file format.
  • Users can create and host ‘social data’ in any tool and on any server, or using a site like Facebook.
  • Other individuals request to connect to the socnet feed of a user, who then accepts them, but can limit–at the individual level–which feed elements (files and folders) the individual can read.
  • Any tool requiring socnet data is granted it by the reading individual. So your contacts app would point at your socnet aggregator app; your calendar app, too; and so forth.
  • Status updates and media sharing are just like normal RSS, basically: a content category, but based on one entity (user, business, group) instead of a site or search.

Result: A platform-independent social networking protocol that abstracts user data out of sandboxed services.

Major Bonus: Contact data is only maintained in one data store: the user’s! No more obsolete contact details, for those to whom you subscribe. Personal calendars could be similarly driven. Anything you’d need to share and sync that currently requires manual data entry or linking.

Dec 042017
 

Basic design: a brick in your pocket with a giant battery, all the RAM, CPU, and storage. A Bluetooth earbud with also a giant battery (must last a day always on).

Use cases: Leverage all the voice-activated functions of current chat bots.

User merely speaks all commands, text messages, calendar events, etc.

Bluetooth keyboard and Wi-Fi screen pairing, when you gotta type to configure or install.

End result: A smart device that never dies (if charged daily) and JUST WORKS. Talk to ‘yourself’ and let the system click icons and type on a tiny screen.

Oct 112017
 

Today

  1. A given quantum of information is sourced in a root language, which could be a single language organization-wide or multiple languages.
  2. Structured markup languages provide metadata and semantics irrespective of eventual output formats.

Concept

  • Continue the abstraction of information in B by eliminating A above as well: content is divorced from format and language.

Implementation

  1. Codify grammar into conditions, objects, actions, results, and all other relevant dictional objects. (Consider the constructed language Unker for models of logical, nonlinear grammar diagrams.)
  2. Document conceptual, procedural, and reference information as information maps that diagrammatically describe the information.
  3. Develop Dictional Style Sheets (DSS) that render the information maps into textual, visual, or even multimedia deliverables. (For textual DSS, additional transformation via CSS and such continues as in B above).

Simple Example

Intent

“The door-open chime sounds and the door-open dashboard light illuminates when a door is ajar while the key is in the ignition.”

Information Map of Objects and Relationships

COND:[(OBJ:car-door:any)open AND (OBJ:key)inserted]
<=>
RES:[(OBJ:door-chime)on AND (OBJ:door-dash-light)on]

COND:[(OBJ:car-door:any)closed AND [ (OBJ:key)inserted OR (OBJ:key)removed] ]
<=>
RES:[(OBJ:door-chime)off AND (OBJ:door-dash-light)off]

REL:alert-types(OBJ:door-chime, OBJ:door-dash-light, …)

DSSs

[Magic happens here. LOTS of object:style mappings, but only need to be done once for each dictional output. Free translation; free infographics; free texts: all from running the information maps through DSSs and then output generators that can handle the renders. A tiny example:]

OBJ:key == “ignition key” | singular-only |

Outputs

Conceptual Contexts

“The door-open chime sounds and the door-open dashboard light illuminates when a door is ajar while the key is in the ignition.”

“When the door is closed, the door-open chime does not sound and the door-open dashboard light does not illuminate, regardless of whether the key is in the ignition or not.”

Procedural Contexts

“To test the door-open chime and the door-open dashboard light, insert the ignition key into the ignition switch and open a door.”

Troubleshooting Contexts

“If the door-open chime is sounding and the door-open dashboard light is illuminated, one or more doors is ajar. You can stop the alerts by either closing the open door or by removing the key from the ignition.”

Infographics

[You’d have graphics mapped to objects and relationships in the DSS that, when generated as output, show up like, say, an Ikea or LEGO manual. In fact, see Lego Digital Designer for a great model of a user interface for assembly mapping by sub-assemblies and stages.]

As you can tell if you’ve read this far, this isn’t a new idea: there are conlang folks who’ve thought about this stuff for decades, but not typically from the perspective of one:many translation (rather more like many:one ‘interfaces’ via written and/or spoke languages).

And I also just realized that many of the OBJ-REL information maps could be scraped straight out of software code! *headsplode*

Descent 1E Condition Checker For Android

 Application, Design  Comments Off on Descent 1E Condition Checker For Android
Feb 212011
 

Motivation

Descent Condition Checker ScreenPlaying Descent: Journeys In The Dark (1E) can be an exercise in confusion, especially when one has several conditions in play, is a Necromancer, and is wandering through a trapped dungeon. My second app for Android, built using App Inventor, is designed to make such checks fast and error-free.

The Application

Here is a link to the APK file for the application:

Descent Condition Checker For Android

Descent Condition Checker QR Code

The Logic

The app is simple enough: click the condition button and it checks against one of three subroutines, as appropriate to the particular condition: rollBlank, rollSurge, or rollPowerEnh. Based on whether TRUE or FALSE is returned by the subroutine, a specific message is displayed in the results area at the top of the screen.

Problems

The following code is supposed to delay a bit and show some text after a button press, to confirm the press for the user:

Descent Code Block Problem

The RESULTS text change, however, does not work properly, no matter where I call for it (even if I make the text change its own procedure). I have to assume that this is a bug with App Inventor, because the exact same calls are used to make the results area change its text based on check results, as well as its background color (green for good-for-the-user results, red for bad-for-the-user results).

Credits

Descent: Journeys In The Dark is ™ and ©2011, Fantasy Flight Games, all rights reserved.

Descent Condition Checker For Android app is ©2011, David Carle Artman, CC-BY NC 3.0.

IAWA Oracles For Android

 Application, Design  Comments Off on IAWA Oracles For Android
Jan 312011
 

Motivation

IAWA Oracles ScreenI decided to try out Google App Inventor, being invited to the Beta. I wanted a simple enough project to get a feel for the process without becoming bogged down in complex logic or user interface (UI) design. It occurred to me that a random Oracle generator for the In A Wicked Age role-playing game by Vincent Baker would be interesting enough and maybe even useful to others.

The Application

Here is a link to the APK file for the application:

IAWA Oracles For Android

IAWA Oracles QR Code

The Logic

App Inventor uses OpenBlocks as a visual programming environment. Very cool for beginners, but also very mouse-intensive when one has repetitious tasks (like pasting in 208 lines of text!)—I’d have liked to be able to edit a TXT or XML file to populate the Oracles lists.

Here is an image of the basic logic for the Blood And Sex Oracles button:

IAWA Oracles Logic Blocks

Nothing too fancy going on here:

  1. Copy the set-specific list to the OraclesCurrent temporary list.
  2. Call the generic procedure that populates the Oracle labels:
    1. Populate the first Oracle label element’s Text with a random Oracle from the list.
    2. Set the second label’s text to the same value as the first.
    3. While the second is the same as the first, populate the second with a random Oracle from the list.
    4. Repeat Steps 2 and 3 for the remaining two label elements, checking them against all preceding labels.
      Put another way, an Oracle label element can not contain the same Oracle text that is currently in any preceding label element.

The rest of the app is a simple UI of buttons for choosing an Oracle set (the BloodAndSex.Click event in the logic shown) and, of course, four global list variables (one-dimensional arrays) to hold the Oracle-set-specific text (the OraclesBloodAndSex in the logic shown).

Credits

In A Wicked Age is ©2007, Vincent Baker, all rights reserved.

IAWA Oracles For Android app is ©2011, David Carle Artman, CC-BY NC 3.0.

Food Bank Coordination

 Application, Design  Comments Off on Food Bank Coordination
Jan 072011
 

Challenge

Municipal food banks depend upon food donations to serve the hungry. Coordinating donors with bank locations becomes a logistical challenge:

  • Picking up donations in a timely manner, without disrupting donor business
  • Distributing donations to banks that need them most
  • Accounting for the storage space of banks
  • Transferring food between banks, if actual numbers do not align with projected needs

Use Cases

A donor registers what they have to donate on a Google map, and chooses a range of pickup time (e.g. a restaurant will usually want it to be between 2pm and 4pm; a grocery store might prefer 10pm to 2am). Options to schedule recurring pickup days, dates, and times.

A recipient registers current stock (one-time, upon setup), storage maximums by volume or weight or other? (one-time, upon setup; and if storage increased), pickup minimums by volume or weight (below which it’s not worth the bank’s costs to pick-up; adjustable as needs change), and projected need (daily, weekly; based on history, once sufficient data is accumulated).

A bank’s delivery drivers are given a “traveling salesman” shortest route to pickup donations equivalent to the bank’s projected need. When they commit to the route, those donations are not made available to other banks unless released later by the receiving bank (to be re-distributed where most needed).

Architecture

Initial setup form, as donor only or recipient/donor.

Site (donor or bank) location definition, via manual text entry, push-pin on Google map, or GPS.

Secure verification of valid bank via server check against state or municipal registries.

User deletion of “bad” donor locations -OR- “bad” donor location reporting and server-side banning.

Multiple location support, for owners of several donor businesses or managers of multiple food banks.

Route navigation interface, once a bank’s delivery drivers commit to best-route pick-ups.

Option to use less efficient routing, if necessary to deliver more balanced meals at a given bank or system-wide.

Historical data storage, server-side or locally, for need projection for a given distribution period (day, week, month?).

Optional automatic application of need projections based on historical data, with ability to adjust before submitting to server for distribution.

Costs

Application development and maintenance – Open source community? Grants?

Validation of food banks against municipal or state charters – Possibly manual labor; possibly automatic with connection to government systems.

Server-side data accumulation and re-distribution to apps – Possibly a function of a public Google map; more likely hosted via grant or by government servers.

License

Creative Commons 3.0 BY-NC-SAThis work is distributed by David Carle Artman under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 License.