The essential news about content management systems and mobile technology. Powered by Perfect Publisher and XT Search for Algolia.
The News Site publishes posts to the following channels: Facebook, Instagram, Twitter, Telegram, Web Push, Tumblr, and Blogger.
Read more https://groups.google.com/d/msg/frameworkonframework/WLaMPiuE1gs/4HM_3qT61TAJ
Cerebro is a WebGL visualisation of Google Analytics data, created by Vetrenko Maxim. You can use the author’s Google Analytics data, or your own – the project isn’t open source, so I decided to use the sample data.
It supports Leap Motion input, and uses three.js, sparks.js, and dancer.js for audio. I couldn’t get it working in Firefox, but it worked in Chrome.
Snowmen War (License: CC BY-NC 3.0) by Tanguy Sauvin and his girlfriend is a WebGL game with some pretty extreme text. When the game starts, you’re warned that “THEY WILL KILL YOU”, and if you’re hit too many times the game over screen simply states “YOU’RE DEAD.” It’s blunt, which is amusing next to the slightly surreal snowmen in outer space visuals.
If you view the project’s source you can see the game engine, which uses Cannon.js, and plenty of Mr.doob’s libraries.
Mark Vasilkov wanted to make something with Goo Engine, so he came up with Cube Game. His advice is to mash the spacebar repeatedly until you win, but I found it was more playable when I realised it’s possible to slide under some of tile-like blocks.
Read more https://feedproxy.google.com/~r/dailyjs/~3/WHV86o9fq5I/cerebro-snowmen-cubes
Back in 2012 it was predicted that 2013 would be the year of mobile devices. More than 50% of the web would be viewed with a mobile device. Therefore it was smart to make sure your website was viewable on mobile.
Now 2013 has come and gone we can see in our statistics that “desktop” machines are still on the winning side. However we can also see that the “mobile” side is gaining weight, on some sites growing with more than 10%.
Time for DOCman to join in and implement a complete responsive design[1]. Here is an overview of the changes we are working on.
One of the biggest changes we are making is going from a multiple column layout to a one column layout. This is needed to make sure we can be responsive across each and every Joomla template and device.
The problem with Joomla templates is that they are all different and we don’t exactly know what the template dimensions are, so we also have no idea when you have to go from a one-column layout to a two-column layout. The only way to solve this is by using a one column layout.
Say you have a website that looks like the image above. Area’s A and C are modules and area B is the docman component. At the moment we’re looking at a single document view.
When working with responsive layouts you only know the width of the browser window which in this case is 1024 pixels wide. So let’s say that in our component both the – title and text area – and the – download button/document info area – should at least be 250 pixels in width to look good and be readable. This counts up to 500 pixels in width.
We could do the following: If the width of the browser window gets smaller than 500 pixels make sure that the columns are stacked vertically instead of aligned horizontally. The only problem is that, as you can see in the picture, the parent element of the component container is only 400 pixels wide at this moment. So both columns are just 200 pixels wide which isn’t big enough.
We could add some JavaScript to calculate the width of the parent. But it’s a better idea to come up with a more solid solution that has a less heavy way of doing things. Thats why we ended up with a single column layout.
Next challenge. What are we going to do with all the info like “Created date” and “File Size” etc.? Placing them below the description might result in them falling off your screen if the descriptions get too long. placing them on top right below the title will almost always make your descriptions disappear on smaller screens.
That’s why we went for the third option. Placing all that info with already existing areas such as the download button and title.
We moved the file size, document extension and document name to the download button and the created date, modified date and author was moved to a small subline right below the title.
When document titles are set to “direct download” the download button in document tables will disappear and the file extension and file size info will appear next to the title. Also the image of the document will never get bigger than 50% percent so the title will always be readable even on smaller screens.
For the user interface rebuild we used a mobile first approach[2]. Mobile first means that you start designing/coding for the least capable machines. Old feature phones with a very basic browser for example. The more capable the device gets the more features you can add. The same goes for design. The wider the screen gets the more things you can align next to each other.
By making sure you work with a mobile first approach you can be sure that everybody is capable to view your content. This doesn’t mean that it looks the same everywhere. In contrary, it looks and works as good as it gets on that particular device.
You can expect these changes in the final release of DOCman 2 which is in testing phase at the moment.
Read more https://blog.joomlatools.com/2014/01/docman-2-gets-a-responsive-design.html
Read more https://feeds.joomla.org/~r/JoomlaExtensionsUpdated/~3/czrT4uTXwFc/11585
Conductance (GitHub: onilabs / conductance, License: GPL, npm: conductance) from Oni Labs is a web application server with a UI toolkit and a module system that’s compatible with client-side code.
It’s built on Stratified JavaScript, by the same company, which adds new language primitives for block lambdas, destructuring data, arrow function syntax, and more.
Conductance already has a detailed tutorial, and there’s an API guide as well.
Easymongo (GitHub: meritt / easymongo, License: MIT, npm: easymongo) by Alexey Simonenko is a wrapper around the native Node MongoDB driver. It has a clean, idiomatic API, and relies on plain old objects instead of models.
It has Mocha tests, and the API is documented in the readme. Basic use looks like this:
var options = {
dbname: 'test'
};
var mongo = new require('easymongo')(options);
var users = mongo.collection('users');
var data = { name: 'Alexey', surname: 'Simonenko', url: 'https://simonenko.su' };
users.save(data, function(error, results) {
// Returns a new document (array).
console.log(results);
});
users.find({ name: 'Alexey' }, { limit: 1 }, function(error, results) {
// Always return array of documents.
console.log(results);
});
What do you do when you’re using simple objects without an ORM layer? You use schemas to validate your user input! Schema-Inspector (GitHub: Atinux / schema-inspector, License: MIT, npm: schema-inspector, Bower: schema-inspector) by Sebastien Chopin is a JavaScript object validator that works in browsers and Node.
Given a suitable schema, you can validate objects like this: inspector.validate(schema, candidate)
. It can also be called asynchronously, which allows you to report issues with this.report
inside functions in the schema.
It has tests written with Mocha, and a healthy amount of API documentation in the readme.
Read more https://feedproxy.google.com/~r/dailyjs/~3/I8FctiGiqzM/node-roundup
Page 829 of 1308