Editor

Preferred Editor?

What is your prefrred editor for web pages these days?

As members (and many readers) likely know, Web Professionals runs a national web design contest every year. This year will be our 15th year. For the past decade, we have recorded the technology used by individual team members to create their web pages. As one may expect a number of different editors are used. Each team has their preferred editor. For most of this time, we noticed Dreamweaver as the premiere editing tool being used by high school students and post-secondary students. This morphed in recent years to many using Sublime Text, Atom, or Brackets. We also saw an uptick in the use of Adobe Muse. We recognize many practicing professionals use a variety of tools. We also saw this week that Adobe announced the end of feature updates for their Muse product. We then heard from a number of teachers that they are concerned about the demise of Muse (many teach design students, not those specializing in web technologies). Frankly, we were surprised that so many have come to rely on Muse as an entry to creating web pages. We also have seen Adobe Spark being used.

We recognize there is a disconnect between what is being taught in schools and what practicing professionals need to know. We see this first hand every year in the comments from judges in our web design competition. As one may suspect, we focus on web standards, process, and user experience (and don’t promote any specific editor). We do see trends and were surprised to see Muse being used in the competition for a couple of years.

This got us thinking about editors in general for web pages. We would like feedback from those visiting this page. What is your preferred editor for web pages? We have included a list of some editors which we have seen being used in our national competition (along with a few others we use). It would be most helpful if you took a moment and voted as to your preferred editor. If you don’t see it on the list, please let us know via comments. We set this poll to display these editors in a random order (trying not to influence the results).

Note: There is a poll embedded within this post, please visit the site to participate in this post’s poll.

Of course, this brings up the bigger question of what should be taught in schools (particularly high schools). We have been promoting web standards and user experience, not specific tools. Does this still make sense? We are keen to learn your thoughts and look forward to a number of insights and comments.

Best always,

Mark DuBois
Executive Director and Community Evangelist

The post Preferred Editor? appeared first on Web Professionals.

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Testing out node and express without a local install or editor

Node.js and Express.js based web apps are getting a lot of attention these days. Setting up the environment is not rocket science, but might be too much effort if all you want to kick the tires of this technology stack.

created

Here’s a simple way to play with both for an hour without having to install anything on your computer or even having access to an editor. This is a great opportunity for showcases, hackathons or a quick proof of concept.

The trick is to use a one-hour trial server of Azure. You don’t need to sign in for anything other than an authentication and you can use Facebook, Google or a Microsoft account for that. You can edit your site right in the browser or by using Git and you can export your efforts for re-use after you discarded the trial server.

Here’s the short process to start playing:

  1. Go to http://tryappservice.azure.com/
  2. Make sure “Web App” is selected (it is the default)
  3. Click “Next”
  4. Select “ExpressJS”
  5. Click “Create”
  6. Sign in with a Facebook, Google or Microsoft account. *
  7. Wait for the server to get set up (1-2 minutes)
  8. Click the URL of your app to see it
  9. Select “Edit with Visual Studio online”
  10. Start editing your site live in the browser

* This is a prevention measure to avoid people spawning lots of bots with this service. Your information isn’t stored, you won’t be contacted and you don’t need to provide any payment details.

You can also clone the site, edit it locally and push to the server with Git. The server is available for an hour and will expire after that. In addition to Git you can also download the app or it’s publishing profile.

Video

There is a quick video of me showing setting up a trial server on YouTube.

Video transcript

Hello I am Chris Heilmann and I want to quickly show you how to set up a
node and Express.js server without having to install anything on your computer. This is a good way to try these technologies out without having to mess with your settings, without having to have an editor. Or if you want to show something to a client who don’t know what node and express do for them.

What you do is you go to a website that allows you to try out Microsoft Azure without having to do anything like buying it, or signing up for it or something like that.

Everything happens in the browser. You go to tryappwebservice.azure.com and then you say you want to start an application. I say I want to have a web application and if I click Next I have a choice of saying I want an asp.net page or whatever. But now I just want to have an Express.js page here right now. I click this one, I say
create and then it can sign in with any of these settings. We only do that so spammers don’t create lots and lots of files and lots and lots of servers.

There’s no billing going on there is no recording going on. You can sign out again afterwards. You can log in with Facebook, log in with Google or you can login with Microsoft. In this case let’s sign in with Google – it’s just my account here – and I sign in with it.

Then I can select what kind of application I want. So now it’s churning in the background and setting up a machine for me on Azure that I will have for one hour. It has a node install and Express.js install and also gives me an online editor so I can play with the information without having to use my own editor or having an editor on my computer.

This takes about a minute up to two minutes depending on how how much traffic we have on the servers but I’ve never waited more than five minutes.

So there you go – your free web app is available for one hour and will expire in in 58 minutes. So you got that much time to play with the express and Node server. After that, you can download the app content, you can download a publishing profile (in case you want to stay on Azure and do something there). Or you can clone or push with git so you can have it on your local machine or you put it on another server afterwards.

What you also have is that you can edit with Visual Studio “Monaco”. So if I click on that one, I get Visual Studio in my browser. I don’t have to download anything, I don’t have to install anything – I can start playing with the application.

The URL is up here so I just click on that one. This is of course not a pretty URL but it’s just for one hour so it’s a throwaway URL anyways. So now I have “express” and “welcome to express” here and if I go to my www root and I start editing in my views and start editing the index.jade file I can say “high at” instead of “welcome to”. It automatically saved it for me in the background so if I now reload the page it should tell me “hi at express” here. I can also go through all the views and all the functionality and the routes – the things that Express.js gives me. If I edit index.js here and instead of “express” I say Azure it again saves automatically for me. I don’t have to do anything else; I just reload the page and instead of “express” it says “Azure”.

If you’re done with it you can just download it or you can download the publishing profile or you can just let it go away. If you say for example you want to have a previous session it will ask you to delete the one that you have right now.

It’s a great way to test things out and you don’t have to install anything on your computer. So if you always wanted to play with node.js and express but you were too timid to go to the command line or to mess up your computer and to have your own editor this is a great way to show people the power of node and express without having to have any server. So, have fun and play with that.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Event listeners popup, @media sidebar, Cubic bezier editor + more – Firefox Developer Tools Episode 33

A new set of Firefox Developer Tools features has just been uplifted to the Aurora channel. These features are available right now in Aurora, and will be in the Firefox 33 release in October. This release brings many new additions, especially to the Inspector tool:

Event listeners popup

Any node with a JavaScript event listener attached to it will now have an “ev” icon next to it in the Inspector. Clicking the icon will open a list of all the event listeners attached to that element. Click the debugger pause icon to get taken to that function in the Debugger, where you can set breakpoints and debug it further. (development notes & UserVoice request)

Event listener popup screenshot

@media sidebar

There’s a new sidebar in the Style Editor which displays a list of shortcuts to every @media rule in the stylesheet you’re editing. Click an item to jump to that rule. The condition text of the rule is greyed-out if the media query doesn’t currently apply. This works well in conjunction with the Responsive Design View (Opt+Cmd+M / Ctrl+Shift+M) for creating and debugging mobile layouts. (development notes)

@media rules sidebar

Add rule

Right-click anywhere in the Rules section of the Inspector to get an “Add Rule” option. Selecting this will add a new CSS rule, pre-populated with a selector that matches the currently selected node. (development notes & UserVoice request)

Add rule screenshot

Edit keyframes

Any @keyframes rules associated with the currently selected element are now displayed in the Rules section of the Inspector, and are editable. This is the first step on the way to better debugging of CSS animations. (development notes)

Editing @keyframe rules

Cubic bezier editor

To aid in editing easing animations, there’s now a cubic bezier editor tooltip that appears when you click the icon next to an animation timing function in a CSS rule. This feature used open source code from Lea Verou’s cubic-bezier.com. (development notes)

Transform highlighter

There’s now an awesome way to visualize how an element has been transformed from its original position and shape. Hovering over a CSS transform property in the Inspector will show the original position of the element on the page and draw lines mapping the original points to their new positions. (development notes)

Transform highlighter screenshot

Persistent disable cache

You can disable the browser cache while you’re developing by checking Advanced Settings > Disable Cache in the Settings tab. Now this setting will persist the next time you open the devtools. As usual, caching is re-enabled for the tab when you close the tools. (development notes & UserVoice request)

New Commands

New commands have been added to the Developer Toolbar (Shift+F2):

inject
The new inject command lets you easily inject jQuery or other JavaScript libraries into your page. Use inject jQuery, inject underscore, or provide your own url with inject <url>. (development notes)
highlight
The highlight command takes a selector and highlights all the nodes on that page that match that selector. (video)(development notes)
folder
The folder command opens a directory in your system’s file explorer. Use folder openprofile to open your Firefox profile directory. (development notes)

Editor preferences

A host of editor preferences are now available in the Settings panel. From here you can change your indentation settings and change editor keybindings to Sublime Text, Vim, or Emacs. (development notes)

WebIDE

A big feature called WebIDE has landed, but is behind a preference for this release while it gets more testing. WebIDE is a tool for in-browser app development. See WebIDE lands in Nightly for more details.

Other features

Edit selectors
Click the selector of any CSS rule in the Inspector to edit it. (development notes)
Black boxed minified sources
JavaScript sources with “min.js” extensions are now automatically black boxed. You can turn this option off in the Debugger settings menu. (development notes)
Custom viewport dimensions
The dimensions in the Responsive Design View are now editable so you can input the exact size you want the content to be. (development notes)

Special thanks to the 33 contributors that added all the features and fixes in this release.

Three of the features from this release came from feedback on the Developer Tools feedback channel, so that’s a great way to suggest features. You can also comment here or shoot feedback to @FirefoxDevTools on Twitter. If you’d like to help out, check out the guide to getting involved.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Introducing the Web Audio Editor in Firefox Developer Tools

In Firefox 32, the Web Audio Editor joins the Shader Editor and Canvas Debugger in Firefox Developer Tools for debugging media-rich content on the web. When developing HTML5 games or fun synthesizers using web audio, the Web Audio Editor assists in visualizing and modifying all of the audio nodes within the web audio AudioContext.

Visualizing the Audio Context

When working with the Web Audio API‘s modular routing, it can be difficult to translate how all of the audio nodes are connected just by listening to the audio output. Often, it is challenging to debug our AudioContext just by listening to the output and looking at the imperative code that creates audio nodes. With the Web Audio Editor, all of the AudioNodes are rendered in a directed graph, illustrating the hierarchy and connections of all audio nodes. With the rendered graph, a developer can ensure that all of the nodes are connected in a way that they expect. This can be especially useful when the context becomes complex, with a network of nodes dedicated to manipulating audio and another for analyzing the data, and we’ve seen some pretty impressive uses of Web Audio resulting in such graphs!

To enable the Web Audio Editor, open up the options in the Developer Tools, and check the “Web Audio Editor” option. Once enabled, open up the tool and reload the page so that all web audio activity can be monitored by the tool. When new audio nodes are created, or when nodes are connected and disconnected from one another, the graph will update with the latest representation of the context.

Modifying AudioNode Properties

Once the graph is rendered, individual audio nodes can be inspected. Clicking on an AudioNode in the graph opens up the audio node inspector where AudioParam‘s and specific properties on the node can be viewed and modified.

Future Work

This is just our first shippable release of the Web Audio Editor, and we are looking forward to making this tool more powerful for all of our audio developers.

  • Visual feedback for nodes that are playing, and time/frequency domain visualizations.
  • Ability to create, connect and disconnect audio nodes from the editor.
  • Tools for debugging onaudioprocess events and audio glitches.
  • Display additional AudioContext information and support multiple contexts.
  • Modify more than just primitives in the node inspector, like adding an AudioBuffer.

We have many dream features and ideas that we’re excited about, and you can view all open bugs for the Web Audio Editor or submit new bugs. Be sure to check out the MDN documentation on the Web Audio Editor and we would also love feedback and thoughts at our UserVoice feedback channel and on Twitter @firefoxdevtools.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Reintroducing the Firefox Developer Tools, part 2: the Scratchpad and the Style Editor

This is part two, out of five, focusing on the built-in Developer Tools in Firefox, their features and where we are now with them. The intention is to show you all the possibilities available, the progress and what we are aiming for.

In the first post in the series we discussed the Web Console and the JavaScript Debugger. While these two tools are powerful and provide capabilities to interrogate and alter your web applications, additional tools are available to further enhance the developer experience while building and debugging your apps. In this post we briefly cover the Scratchpad and the Style editor.

As with the first post, we present each tool with a quick screencast demonstrating some of their capabilities.

The Style Editor

The Style Editor is primarily used to edit, debug or create new stylesheets within the context of the current app. Changes made in the style editor are automatically reflected in the loaded page. If you are not familiar with Cascading Style Sheets (CSS), please be sure to take a look at the CSS MDN documentation.

The Style Editor allows saving the changes made while using the editor. In addition you can also import existing stylesheets and apply them to the current page or individually disable specific stylesheets. The Style Editor is also linked to the Inspector allowing developers quick access to the stylesheet for the inspected element. The following screencast presents an overview of the Style Editor’s features.

For more detailed information on the Style Editor take a look at the MDN documentation.

Scratchpad

The Scratchpad has many uses and is essentially a live JavaScript editor and prototyping tool. Using the Scratchpad, a developer can access the current page’s objects, variables and script. In addition, complete functions can be written and tested in the editor within the scope of the live page. These changes can then be attached and saved with the current application.

External JavaScript files can also be loaded and tested. Several run options are available to allow a developer to just execute the code, execute the code and inspect the returned object, or execute the code and print out the results as a comment within the Scratchpad. The following screencast illustrates some of the features of the Scratchpad. Note that Scratchpad script runs in the same
context as a script loaded into the page. In the screencast, the example uses the jQuery library and some custom script to illustrate this feature.

For more information on the Scratchpad, see the MDN Debugger documentation.

If you are not very familiar with JavaScript, make sure to check out the MDN documentation for a comprehensive list of resources on learning the language and mechanics.

Learn More

These screencasts give a quick introduction to the main features of these tools. For the full details on all of the Developer Tools, check out the full MDN Tools documentation.

Coming Up

In the next post, we will focus on some Mobile design features including the Responsive Design View and Remote debugging using the App Manager. Please provide your suggestions on what features you would like to see explained in more detail in this upcoming post, by commenting below.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Gameleon and the map editor – a WebFWD project

More than 9 months ago, we were working on a web game, having all the nice HTML5 stuff like Canvas, WebSocket, CSS3. We were playing a lot with experimental code in NodeJS and Redis. We had all the nice scripts and plugins and quite a good architecture to make the game possible.

We lacked one thing though: a powerful editor. Since we had 8 years of nothing but web development experience, we were keen on making this web too. We didn’t like Flash though or anything which isn’t a web standard or open technology, because it was restricting us from using what we made on all the devices we had through the office, in the same way (tablets, phones, laptops, desktops).

Creating an editor

So, we’ve started making Gameleon for Shay, our game architect. He did quite a lot of Dungeons and Dragons and played with many of the RPG editors out there. We thought that he was good just like that, without any programming knowledge, and we wanted to give him the means to make anything in our game, without coming to us.

The first thing we made was the map editor. One thing was sure about this: we didn’t want to have any kind of limitations, such as tiles. What we love doing is drawing the maps ourselves, in any way we see fit. The one thing you can never know about a random picture is where the obstacles are. For that, we made a polygon editing tool, which can define just that. It is like a mesh applied on top of the map, giving it the logic for collision detection later.

Probably this video demonstrating how a map is built will be of more help:

Processing a map

In this article i’ll try to discuss a bit about how the map is processed and turned into a walkable, obstacle friendly surface.

When it comes to making a friendly way to define areas, using vectors is the way to go, as you probably saw in the above video.

A map is defined by vertices and points. They are sent to the server via WebSocket, in JSON format.

The struggle when having a good map is to have that good mixture between freedom to create as much content as you want, yet be able to determine what surface is an obstacle and have a very fast collision detection system and path finding.

image

The best mix of these two we’ve found to be in a grid. Using A* and QuadTree to determine the shortest route and the collisions between objects, no matter what size, became a lot simpler. By the way, all objects defined on a map, are treated as circles. When we determine if an object collides with another (in a combat situation for instance), we can make one of the objects move to the nearest empty area, while still being in range of the target.

So, this is why we are going to transform the vector map we’ve just received, into a grid, having a square of the size of 8 x 8 points. Experimentally, we’ve determined it is a small enough square to have a small number of collisions, and yet be effective when searching across long distances (for instance, searching for the shortest path between two points A and B on a map of 3200 x 2000 points).

Determining the squares

To determine the squares a polygon is going to cover, we use a brute force technique. Yes, it may sound crude, but it is quite effective. First, we determine the rectangle covered by the polygon.

enhance.prototype._determineRectangle = function( points, poly )
{
    var minX = null, minY = null, maxX = null, maxY = null;
 
    for(var j=0;j<poly.coords.length;j++)
    {
        var currentPoint = points[ poly.coords[j] ];
 
        if( minX == null || currentPoint[ 0 ] < minX )
        {
            minX = currentPoint[0];
        }
 
        if( maxX == null || currentPoint[ 0 ] > maxX )
        {
            maxX = currentPoint[0];
        }
 
        if( minY == null || currentPoint[ 1 ] < minY )
        {
            minY = currentPoint[1];
        }
 
        if( maxY == null || currentPoint[ 1 ] > maxY )
        {
            maxY = currentPoint[1];
        }
    }
 
    return { minX: minX, minY: minY, maxX: maxX, maxY: maxY };
}

image

Checking point positions

Once we have that, we start going through each point of that rectangle and check if the point is inside or outside the polygon. The theory behind this is to draw a horizontal line passing through that point and check the number of intersections with the polygon’s vertices. If the number of intersections is odd, then the point is outside. If the number is even, then it is inside.

enhance.prototype._pointInPolygon = function( x, y, poly, points )
{
    var j = poly.coords.length - 1, oddNodes = false;
 
    for(var i = 0;i < poly.coords.length; i++)
    {
        var pointI = poly.coords[i],
            pointJ = poly.coords[j],
            _pointIY = points[ pointI ][1],
            _pointJY = points[ pointJ ][1],
            _pointIX = points[ pointI ][0],
            _pointJX = points[ pointJ ][0];
 
        if(
            _pointIX == x &&
            _pointIY == y
        )
        {
            return true;
        }
 
        if(
            ( _pointIY < y && _pointJY >= y ) ||
            ( _pointJY < y && _pointIY >= y )
        )
        {   
            if(
                _pointIX + ( y - _pointIY ) / ( _pointJY - _pointIY ) * ( _pointJX - _pointIX ) < x
            )
            {
                oddNodes = !oddNodes;
            }
        }
 
        j = i;
    }
 
    return oddNodes;
}

This way, we mark the walkable and non-walkable areas of the map. However, there are those special situations when you want to mark an area as walkable or non-walkable dynamically.

image

Say you have some debris and you don’t want that area to be walkable, but once the debris are destroyed, that area has to be changed. So, we keep in a separate vector, the actual points covered by each polygon.

Setting names

In the map editor, you are being given the ability to name polygons, both for esthetic purposes – to notify the player that he is entering “The Killing Fields” for instance, and to lookup via scripting.

The scripting names are automatically given – ZP01, ZP02, etc. – to ensure their unique name.

In the script editor, you can use an action named setWalkableArea, and send as parameter the polygon name. When the action is executed, the server will broadcast to every member on the map, the points which are suppose to change their state, thus updating the map grid with ease. No additional processing will be done.

image

Say you attach this to the event of an object being destroyed, which was right on top of that area. This would create the illusion that the object itself was an obstacle and that it is now removed.

Neat, isn’t it?

Part of Gameleon

The code above is part of the editor and this coding standard can be found throughout the entire Gameleon code.

Hope you enjoyed this short intro into how we see maps and games being created. If you want to know more, have a look at Gameleon and follow us on twitter: @gameleonMain.

The complete source code is available on GitHub.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: +1 (from 1 vote)