mozilla / webmaker-addons Goto Github PK

AFAIK, this can only reliably be done with an add-on.

Will likely want to consult the source of an existing add-on that has such functionality, like Colorzilla

Hey @xmatthewx could you transfer this repo to the mozilla org so more people have access to it?

Images should be scaled to fit the canvas/whiteboard with max-width since sidebar will be full screen width. Not to be confused with #15 to resize large image files.

@toolness https://www.dropbox.com/sh/3jul0vlv17u3l2p/AAC4LezlqeB0KHUoyMpIlSfTa?dl=0

If I make the sidebar narrow and import a large image, it is squeezed to fit in the sidebar, and the slider won't let me grow past 100%.

The easiest thing is maybe to let people resize the image by grabbing a corner, as opposed to using a slider?

Borderline MVP - if one interaction could be made beautiful ...

When I user taps to share/edit an image, it would be great to clone the image and nicely animate it's appearance in the edit space.

Firefox is really, really, really bad when it comes to getting blobs out of the browser and onto the user's filesystem.

Dragging an image with a blob or data URL to the desktop is completely useless in Firefox (it works fine in Chrome though). Using the download attribute does the job when in a normal browser tab, but in a sidebar it uselessly opens the image in a new browser tab.

We'll likely have to change the sidebar to post a message to the addon, which will then use some obscure, undocumented Gecko API to open a download dialog for the user.

For the time being, though, it looks like users will just need to right-click the image and choose "Save As...".

move add-on to right side of browser

What this means for us is that when there's <text font-family="FontAwesome"> in an SVG, the embedding HTML page isn't consulted for that font, so any glyphs using the font don't show up as intended unless the user has the font installed globally on their filesystem.

For instance, this is what src/icons/TrashIcon.svg looks like when embedded in reference.html on my system, which doesn't have Font Awesome installed at the OS level:

One possibility might be to figure out how to link to a CSS stylesheet in the SVG file itself, if that's even possible, but I'm not a huge fan of that because it makes the SVG non-portable if the URL isn't absolute. It would probably be easiest to just tell Sketch/Illustrator to vectorize text when exporting, though it will result in larger SVG files.

Clarify the scope, market, etc. of the tool being thought about here: MozillaFoundation/plan#123

Currently the addon's content script only goes into the top-level page elements, which is super lame.

I like the animation in #10. It's fun and helps explain this unfamiliar experience. When the sidebar is already open, it works smoothly.

Adding the first image, however, there's a big lag between step 2 and 3.

1. animate image on page
2. open sidebar
3. animate image in sidebar

The sidebar background colors aren't there initially. If the image lag is unavoidable, adding the colors and a spinner will help.

Trying to avoid a big branding discussion here, so maybe we just remove the header for now?

I keep hitting the + button instead of the archive button in gmail =)

It would be cool if there was an eyedropper on the font selection menu that allowed the user to click on any text in the current tab, and automatically slurp in its font.

This will be a bit tricky because of CORS difficulties; at the very least, when publishing to HTML, we might need to use a CORS proxy, or embed the font as a data: URI or somesuch.

In #10 we animate the image from the content to the editor by creating an <img> element and animating it off the screen. It's assumed that this element will precisely superimpose the one that the user is looking at, but this isn't necessarily the case with background images, which may be cropped or other things through all the fancy background-* CSS properties. This means that the animation may be a bit disorienting.

However, there's more... once the image gets to the sidebar, none of those background properties are applied either, so if the background image was actually a very specific part of a spritesheet, the entire spritesheet gets added to the canvas.

The solution here might actually be to simply make all images in the editor be represented using CSS background properties, which satisfies the standard <img> use-case as well as these more funkalicious ones.

I have no idea if it's doable or not, but if the exported PNGs had embedded metadata (including a JSON blob of the "source" of the image), then you could imagine that opening these images would let us make them be remixable after the sharing flow.

Export to facebook, find in facebook, open in firefox, firefox detects it as a remixable image, can be opened in the sidebar.

On sharing, offer a "copy url" button if it can be implemented in a half hour or less. I will post a mockup or reference for the sharing modal.

Not a bug. Not an MVP feature.

Our prototype as built allows users to pull in animated GIFs and overlay text etc. They could even overlay multiple GIFs and SVGs.

This creates a beautiful conflict: if they share this on a platform like facebook, they will get a static version. If they share via Webmaker, they can preserve the chaotic animated beauty.

We could add a feature to generate a new animated gif. Not MVP. While it might remove the conflict, it will make this a much more interesting tool for a broader audience.

@toolness had the great idea of baking our json blob into the pngs we generate so that images could be later pulled into Webmaker and edited. Not MVP, but something to keep in mind.

Currently clicking on the Facebook icon when sharing just raises a modal telling the user that the feature is unimplemented. We should actually upload the image somewhere and then use various social network sharing APIs to blah

Aside from being fundamentally good to attribute one's sources, I think it could have a few other benefits, depending on how we surface the information.

For example, if we hyperlink the images to the pages they came from in the HTML/Webmaker-exported version of the make, it could result in novel use cases... Maybe a visual way of sending "lists" of links back and forth?

Once a user has opened the sidebar, we should indicate that additional images can be pulled into this space. We can highlight all the images on the page and include a + icon or ⤢ to show you can add or drag it.

Images should be resized if they are crazy big when added. 800px x 600px seems like a reasonable default for now.

This is what it looks like in reference.html:

I guess doing a lot of the social network options will mean hosting the image somewhere first.

It might just be because I'm working on the addon while having the addon installed, which results in weird inception-y situations, but I'm finding myself getting confused on occasion, thinking that the "+" icon that appears over images is some kind of feature of the web page I'm on, rather than the web browser I'm using.

Not sure if this fully makes sense, we can just close the issue if nobody else is experiencing the same problem.

The picker can be seen in reference.html, here's a screenshot for quick reference:

It'd be cool if the addon code observed relevant preferences, particularly services.sync.account, to dynamically react to changes in the browser without requiring a restart of the addon.

Feedback started here: MozillaFoundation/plan#177

@toolness - I took a stab at the list of priorities. feel free to edit, add, or comment.

top priority

• iterate on ui to match reference.html
• hook into css background images (7c14433)
• add new svg plus icon (a75d6ee)
• wider sidebar width by default

next

• resize handle
• drag-drop to add image
• move panel to right side of window

nice to have

• color picker
• add-on preference to turn it on-hover/on-always/off
• right-click to change canvas uri

• Remove references to Webmaker
• Remove "save as HTML" functionality

Try a corner handle to resize font-size.

Alt 1

If it gives you trouble...

• change background color of slider as below
• relabel as Small/Large instead of Fontsize/60px

Alt 2

• Might consider a button group of if resize handle on fonts doesn't feel right for users

• user can
  • start a new creation via context menu on image
  • add images via...
    • device via file picker
    • drag from html page
    • small collection of stickers
  • add text on image with a few style options
  • share as...
    • image to one social platform
    • new page in thimble or another tool

@toolness - I will let you decide if you want issues for individual features or if you want to keep this meta for now.

For building, testing, and demos, it's nice that we're using a single firebase url rather than constantly refilling a blank canvas. A side effect is that the tool becomes collaborative.

Later, when we shift to unique urls, it'd be nice to plant a right-click option to copy your random url or paste in a friends for collaboriation. Not essential, but a nice bonus.

Put the image somewhere so we can share to a social site. Image storage can expire. This is a scratchpad for makers, not image hosting.

Images can currently be added via URL for testing. Ultimately, we want users to add them via the page.

To prototype this, we can either split our screen with fake "page" on the left and "app" on the right, or we can start packaging this as an addon.

Scenario A - Page fills entire window. User picks an image (right click for now). Sidebar opens with image in it.

Scenario B - Sidebar is open. User drags an image from the page to add to sidebar.

allow users to drag images and text from a page to the sidebar

It feels to me like small icons aren't likely useful, and the +'s definitely get in the way of generally using the web.

Design refined ux and ui based on the plan: MozillaFoundation/plan#123 (comment) for prototype: MozillaFoundation/plan#125

This is particularly done after saving an image, closing the save-image modal in the sidebar, and then dragging the image into the sidebar. In Firefox a red "nope" icon appears as the image is dragged over the sidebar.

What tools do people use to manipulate photos and found content? What tools do this within a platform like instagram and between platforms? How do people string together tools to make things beyond the intentions of the tool?

Understanding how people hack the gaps between existing tools & platforms will enable us to make a unique thing that people actually want to use. Mapping these tricks can help us create a tool that cracks the divide between closed and open publishing.

Apps

• Tumblr
• Instagram (IRL)
• Over
• Snapchat
• Glitchr
• Skitch
• Pixlr
• Aviary SDK

Add-ons

• Awesome Screenshot - Diigo
  • 1.3m users of chrome extenstion
  • 200k users of Firefox add-on
• Stylish - user style sheets
  • 750k users of Firefox add-on, 1% on android
• "instagram for chrome"
  • 1.2m users

Also ran

• shu - FF
• GooEdit - Chrome
• Photon - Facebook Photo Editor - Chrome

Others?

For instance, a number of images on yahoo.com are invisible elements floating atop images (it seems to be some kind of YUI thing). Not sure if traversing the DOM tree will do the job since the two elements may not be related.

Perhaps elementFromPoint() may be useful somehow.

While an item on the canvas/whiteboard is selected, add appropriate style. Such as...

box-shadow:0px 0px 20px rgba(255, 255, 0, 0.5);
cursor:move;

To make things simpler for users, we should select a handful of fonts instead of offering all the fonts.

We might also fetch the characters in their name so we can show how they look in the menu itself. Like so: http://fonts.googleapis.com/css?family=Opens+Sans&text=OpenSans

A few from the league of moveable type on google fonts:
Knewave
Londrina Sketch
Pacifico
Open Sans
Prociono

What can we show people from this week's thinking? Doesn't have to be finished or flashy. But it's fun and informative.

@toolness - let's add a boundary so people can't completely drag an image off the canvas. try it at a dozen or a half dozen pixels of overlap. see how it feels.

Users who find an image need to trigger the editing and sharing experience. Before they can do that, however, they need to know that it's possible!!

Some people who install the add-on will fully understand that and remember it later. Many or most will not. If we were omniscient, we could ping a user the moment they thought, "Huh, cool. Jane would love that image. It would be even cooler if...." How can we approximate that?

Flavors of See - Tap - Go:

1. Right click - reveals context menu (totally hidden, not touch friendly)
2. Long press - reveals context menu (hidden, fiddly)
3. Hover on image - reveals icon button (pings a user nicely, desktop only)
4. Tap image - reveals icon button* (interferes with site defaults)
5. Mouse move - reveals buttons on all images, fade after delay (nice reminder, desktop only, probably annoying)
6. Scrolling - reveals buttons on all images, fade after delay (nice reminder, can't scroll on short pages)
7. Image in Region - icon button revealed when image passes through a region of the page like top 25% (can't scroll on short pages)
8. Always On - show small, permanent icon buttons on images
9. Activate plugin - make all images selectable or draggable to edit space (hidden in menus, disrupts browsing)
10. other ideas? please share...

* An icon button added to an image would look similar to this, but way less ugly:

As pictoral fonts like Font Awesome are used more and more across the web, it strikes me that people will expect the add-on to be able to import them into the sidebar, since they do look like images.

can't drag an image from browser to desktop

An icon, rather than a text menu item, will likely serve as the button to start the edit/share experience. This icon should be cool, not tame.