Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I would try to:</p> <ol> <li><p><strong>Make it configurable</strong></p> <ul> <li>Load external stylesheets?</li> <li>Where do I find resources I need? (images, stylesheets)</li> <li>What layout/size should I have?</li> </ul> <p>By doing this you let the user decide if he wants your widget to automatically load the stylesheet, or if he wants to host it himself. If he does, he can also update the styles to better fit the page the widget resides on.</p></li> <li><strong>Provide a wizard</strong> for generating a snippet of code to include on the page <ul> <li>Ensures that even moderately technical users can utilize your widget</li> </ul></li> <li><strong>Make it light-weight</strong> <ul> <li>Serve everything minified and compressed</li> <li>Serve with cache-headers, e-tags, last-modified and all other useful headers you can think of. This will both reduce the load on your servers as well as make your widget more responsive.</li> <li>Try to avoid dependencies on libraries, or check if they are loaded on the page where the widget is used before loading them</li> </ul></li> <li><strong>Be wary of conflicts</strong> <ul> <li>Prototype uses $, and so does jQuery. If your widget depends on Prototype, and the page it is hosted on uses jQuery without <a href="http://api.jquery.com/jQuery.noConflict/" rel="noreferrer">noConflict-mode</a>, problems WILL arise</li> <li>Do not clobber the global namespace! <ul> <li>If you don't want anyone to interact with your widget, put it in a self-executing function in a closure and don't create any global variables at all</li> <li>If you want users to be able to interact with your widget, say for adding event listeners and such, claim a single global variable, let's say ExampleComWidget as an object literal and put your methods there. User's could then interact like: <code>ExampleComWidget.addListener('update', callback);</code></li> </ul></li> </ul></li> <li><p><strong>Use clever markup</strong></p> <ul> <li><p>Be sure to use scoping on your classes and ids, to avoid conflicts as much as possible</p> <p>I.e. if your company's name is example.com, you could use classes like: <code>com-ex-widget-newsItem</code></p></li> <li>Validate your markup! You do not want to break a user's site</li> <li>Semantic markup is fine, but you might want to avoid <code>&lt;h1&gt;</code>-tags, since they have especially high ranking in SEO. You could probably get by with using <code>&lt;h4&gt;</code> and less. This bullet might be a bit off. When in doubt, it's much better to use semantic markup than not.</li> </ul></li> <li><strong>Fetch data from your site by inserting script elements</strong> <ul> <li>This is a fool-proof way to ensure that you get around the same-origin restrictions.</li> <li>Attach an onload-listener to the script element to know when the data is ready, or use <a href="http://en.wikipedia.org/wiki/JSON#JSONP" rel="noreferrer">jsonp</a></li> </ul></li> </ol>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload