1. Capture the Relevant Region
Start with the detail someone needs to see, then make its meaning clear.
Visual feedback becomes harder to use when the useful detail is buried inside a full desktop image. MyScreenScraper starts with a direct selection gesture: click the blue lens, press and drag across the required area, then release. The selected region opens in its own editor, ready for explanation.
The capture flow is designed to preserve the relationship between the user's selection and the resulting image. It maps the selection through measured window bounds into the display image, rather than assuming that browser coordinates and monitor pixels are identical. The implementation crops a temporary display frame in memory and retains the selected region.
Cancellation is part of the interaction. Right-click or Escape cancels without creating a file, while a click without a valid drag keeps the selector waiting. This gives the user time to choose the right area. Native Windows display scaling and capture behavior remain part of the product's validation work.
2. Turn an Image into an Explanation
The editor concentrates on a small set of visual tools with distinct purposes. An arrow directs attention, a box defines an area, a callout adds words and a translucent highlight emphasizes content while leaving it visible. One drawing tool is active at a time, with visible selection and a shared six-color palette.
Arrow
Point directly to a control, issue or detail that needs attention.
Box
Frame an area so a reviewer can immediately see the intended scope.
Callout
Add an inline explanation inside a drawn text box with font and color controls.
Highlight
Emphasize a passage or interface element with a translucent color layer.
Undo and redo make revisions manageable. Fit and zoom change the viewing scale without changing exported pixels, and a separate editing Lock prevents unintended marks. Copy uses the current composition without silently saving it; Save exports the composition and retains it in local history. Those separate actions let users decide when a quick explanation becomes a saved artifact.
3. Record When Motion Matters
Some explanations depend on sequence: a menu opening, a repeated error or a series of steps. The version 2.0 source adds a red Video Scrape lens beside the image-capture control. The user selects a region with the same gesture, then starts recording from a floating control. Selecting an area alone does not begin recording.
A visible three-second countdown precedes capture. Stopping opens a local playback window with download and delete actions. The implementation creates WebM recordings at a target of 30 frames per second, with output capped at 1920 × 1080 without upscaling. It supports a region within one display; cross-monitor spanning is outside the current design.
Device access is explicit. A requested but unavailable input produces an error, and recording streams are released after stop, cancellation or failure. Actual microphone, camera and system-audio behavior still needs native Windows verification.
4. Keep Useful Work Close at Hand
Saved images lose value when they disappear into a growing collection of unnamed files. MyScreenScraper pairs saved media with a local history that shows thumbnails, names, dates and sizes, ordered with recent work first. Opening a saved image gives a read-only preview, making retrieval a separate action from editing.
The save workflow supports a preferred destination folder. When one is configured, Save uses it; otherwise, the user chooses a location for each file. The application also keeps its own local history, so exporting an image does not remove it from the working collection. A storage meter helps make that collection visible, and ZIP export gathers saved images and videos into one package.
Keep control of the working session
The main widget and editor have independent pin states, while the editing Lock serves a separate purpose. The main widget returns after capture when pinned and minimizes when unpinned. Closing an edited image asks before discarding changes. Clearing local storage requires confirmation and leaves previously exported copies in place.
5. Share Only When It Is Useful
Local capture and editing are the core workflow. The optional sharing layer extends it for a screenshot or recording that needs to be viewed elsewhere. Users configure an HTTPS server and upload key, enable sharing, and test the connection before the upload control becomes available. Uploading remains an explicit choice.
The source includes a separate PHP/MySQL hosting kit. It stores media privately, returns a copyable share link with a 30-day expiry, and provides expiry checks and scheduled cleanup. Anyone with the link can view the media until it expires, so the user decides which material is suitable to share.
The desktop stores the upload key through the operating system's protected storage, while database credentials stay on the server. A 100 MiB upload limit is separate from local recording storage: a larger recording can remain local. This hosted component is supplied as an installation candidate; live Hostinger and MySQL integration has not yet been validated.
6. One Workflow, Clear Responsibilities
MyScreenScraper uses Electron and JavaScript for the desktop application, HTML and CSS for its interfaces, and Canvas for image annotation and region rendering. Browser media APIs handle the recording path, while filesystem and JSON storage maintain local media history and preferences. The optional PHP/MySQL service has a separate responsibility: receiving approved uploads and serving expiring links.
The product direction is deliberately practical. Capture establishes the visual evidence; annotation adds the explanation; history keeps the result available; recording shows a sequence; and optional sharing carries the finished artifact to another person. Each step has a visible user action rather than making a single capture trigger unrelated work.
That combination creates a coherent desktop utility for review, troubleshooting and everyday visual communication. Its current outcome is an implemented source candidate with controlled test evidence, plus a defined path through native-device and hosting validation.
Current development stage
This case study reflects V2.0-B010 / R12, a source candidate. Controlled checks include WebM encoding with synthetic devices. Native Windows capture, hardware devices and hosted sharing remain under validation; final installer and release acceptance are still open.
