Categoría: Destacadas / Featured

  • gamification o gamificación
    Desarrollo / Development / Destacadas / Featured / Diseño Web / Experiencia de Usuario / UX / Gamificación / Gamification / Ideas / Programación / Programming

    Gamification
    flashw

    Playing while working, studying, exercising or using the web

    Those of us who have been or are gamers know that the idea or concept of gamification has been hovering around forever (at least, about 3 decades). Remember old phrases like, learn by playing! lose weight while having fun! etc. Now, although the concept is old, the term was coined thanks to a computer programmer named Nick Pelling in 2002, but in reality, the concept has begun to attract attention only in recent years.

    Lately, I have met many people who use dazzling terms such as “game mechanics”, “game dynamics” or aims to establish as something complex and laborious the implementation of the concept, confusing the basic idea of gamification with complex marketing campaigns and big data. Certainly, you can create a sophisticated gamification implementation, but based on my experience involved in multimedia development teams since 1998, I can say that a lot about implementing gamification is just common sense.

    Without being or pretending to be an expert in gamification, below I share some ideas, terms, and approaches that I’ve learned over time:

    What is gamification?

    There are lots of sites where you can get nice definitions about what gamification is, but to save the trip to Wikipedia, this is its definition:

    Gamification is the application of game-design elements and game principles in non-game contexts. Gamification commonly employs game design elements to improve user engagement, organizational productivity, flow, learning, crowdsourcing, employee recruitment and evaluation, ease of use, usefulness of systems, physical exercise, traffic violations, voter apathy, and more. A collection of research on gamification shows that a majority of studies on gamification find it has positive effects on individuals. However, individual and contextual differences exist. Gamification can also improve an individual’s ability to comprehend digital content and understand a certain area of study such as music.

    Did you understand that? Basically, it means, turns a task into something more interesting by adopting the logic of a game. The simplest way would be giving some sort of reward for doing some activity. The prize can be as obvious as a trophy or as vague and subjective as simply seeking to offer fun while doing a specific task. But of course, there’s much more that can be done, especially when human behavior is considered.

    But to meet the cliché, this is my personal definition:

    Gamification is the application of the metaphor of gaming to common or compulsory tasks to influence behavior, giving more motivation and increasing involvement, preference or loyalty.

    Are video games useful?

    For some years I was a World of Warcraft player, a very popular video game with millions of users, which I think is a great example of how these games can be related to the real world. Within World of Warcraft, one of the objectives is to make money. This money can be obtained in several ways, but most of it is completing quests (missions). As a result of solving the missions you get gold, which the player uses to obtain different things like buying clothes, weapons, materials, improvements, information for new missions, etc. (Does this sound familiar?), this is the basics of any business and an important part of life. Day by day World of Warcraft players spend their time making goods, offering services and fulfilling missions. In the real world, we do the same, we earn money to obtain some achievement; We spend that money on buying new things or we invest in something that allows us to earn more money or do something more efficiently or comfortably.

    A valid question would be why these players are so willing to spend so much time doing what they could do in real life? The answer is easy: because it’s fun.

    Adopting the idea

    At this point It’s important to clarify that not everything is about video games, we will not see in the immediate future someone willing to play the latest game of Microsoft Project or Word (although, you never know 😉). What we are trying to do is take ideas from games and insert them into some routine task, so these tasks don’t have to be boring to death.

    With all the above in mind I have to be honest, despite the relatively recent popularity of the idea of gamification, not everyone knows what it is, not everyone is interested, it seems that to get hear and understand the term is required of some curiosity, wanting to know what is in vogue about developing, UX, etc., or just having a little bit of geekness. All this makes selling the idea to or in an organization is not as easy as it might seem (at least not here in the third world).

    Recently I participated in a project where customer asked my team, to propose “innovative” ideas (another oversold term) to improve the technological proposal of an organization, as part of this I eventually proposed the idea of incorporating some initial and modest strategy of gamification, giving some overall but concrete examples including just enough detail, not exactly as something “innovative” but as something that only intended to “update” the technological solution implemented at the time. Surprisingly, although the organization which I was working with,  develops technological solutions, 90% of those involved did not know what the hell I was talking about (shame on you Infotec); I had to explain the idea to business analysts, deputy directors, directors, contractors and developers without much success (nobody is a prophet in his own land, but I like to think I threw some light on lost souls).

    I have to add that the word gamification is weird English and the translations into Spanish sound even worse, so the word doesn’t help too much to sell the concept, as a result of this experience I came up to the conclusion that in order to adopt the idea more easily, we must use words such as Productivity, Behavior Changes, Motivation and Preference (or engagement if you prefer the marketing jargon).

    Points, Medals, Trophies, Position Tables

    As responsible for a project some time ago, I needed to make a quality assurance in a series of contents for courses, with a lot of information to review and very little time, I told the members of my team, that the two people who found more errors would earn a big coffee every day for the next week. Suddenly a game was on.

    Fortunately, we do not always need to resort to real physical awards in all cases. The management of information that users provide their organization, website or mobile application can be used to award prizes in different ways, the most common are:

    • Points
    • Medals
    • Trophies
    • Levels
    • Position Tables
    • Challenges
    • Achievements

    En un sitio o sistema web, por ejemplo, el concepto es utilizado ampliamente para que sus usuarios hagan más dentro del sitio o estén más tiempo expuestos a determinada información. Algún sitio donde se hacen trámites, puede hacer del llenado de sus formularios algo más ameno dando alguna especie de puntaje o jerarquía relacionada con un progreso por cada paso completado. Un sitio de ventas puede dar trofeos o medallas por las reseñas que un usuario coloca acerca de algún producto.

    These examples are certainly very simple since only seek to motivate more users to carry out a task, and of course, they leave much more to exploit the concept, but they’re a good starting point to explore the benefits of gamification.

    Not everything is about money

    A strange and limited argument that I came across when I proposed gamification, is that accordingly with someone’s assumption, gamification was about giving economic incentives in the form of cash, coupons or discounts, which of course is not necessarily true, and falling into that assumption usually creates concern and even rejection from the sponsors of any project or production chain. Money is a good motivator for a user (it always is), but there is a word that you will find very often in blogs and books about gamification and also I already mentioned, this is engagement, this means that money will always motivate you doing some task but won’t necessarily “hook” you to it nor will make the activity enjoyable.

    What else?

    If you start to delve deeper into gamification issues, you will eventually realize that there is much more than just depending on incentives and certainly much more than relying on money. You will be using human behavior and the famous reptilian brain, that is, use in your favor something that is within human nature itself, play. Using gamification you will be appealing to feelings of pride and need for recognition, with which you could achieve even more than offering money in exchange.

    In conclusion

    I’ll share with you a couple of videos about some educational projects where I was involved and I used gamification (they’re old but still valid to understand the concept) and some bibliographies that I found useful and interesting:

    Books:

    1. Why we do what we do: understanding self-motivation
    2. For the Win: How Game Thinking Can Revolutionize Your Business
    3. A Theory of Fun for Game Design

    Videos:

    Risk Prevention

    Mexico’s Economic Development

    English Learning Card Game

    Thanks to @Mordred77M  for the English translation, he’s not a natural English speaker and he´s still learning so don’t be grumpy and help him to improve :)

    Related links:

    U.S. Army – America’s Army (Cómo el ejército de E.U.A. ahora utiliza gamification para atraer nuevos reclutas)

    Mint (Empresa con aplicaciones fintech que utiliza gamification para las finanzas personales)

    No Comment
  • Sin Usuarios
    Administración / Management / Administración de Proyectos / Project Management / Agile / Destacadas / Featured

    Without users (User Proxies)
    flashw

    Without Users (User Proxies)

    Ideally, when we pretend to develop a software, we need to talk with one or more real users who are part of the customer team. But, the reality has the bad habit of punching Dilbert and us right in the nose and continuously we found our selves in one of two situations:

    1. We have as primary contacts, people who pretend to guess how a final user wants the software behaves when only the real user actually knows it, and yet we have limited or no access at all to them.
    2. The product is so innovating that we actually don’t have a real user in advance.

    Unfortunately, very often is difficult to get the users that we need. For example, we could be developing a product with user all over the country, but we can’t bring one (or more) of them with us, to write requirements or user stories. Or maybe we could be writing software that will be used inside our company, but somebody says that we can’t talk directly with the users.

    When we can’t get as many users as we’d like us to represent the different perspectives to the product, we have to resort to people or intermediary resources, also known as user proxies, who maybe are not users, but we need to include them in the project in order to represent the users and so deal with the two mentioned situations.

    Warning

    What I going say in rest of this post can be controversial and is subject to my personal experience but is also based on publications (that I always put at the end). This time I will focus on what characterizes each type of user proxy.

    The user proxies selection can be critical to achieving the success of a project. The experience, motivations and possible agenda of a proxy must be considered. A user proxy involved in sales will have a completely different perspective from a domain expert’s. It’s important to be aware of these differences, that is why I’ll try to provide a synthesis of what characterizes some of them.

    Proxies:

    Final users supervisors

    When we try to create internal use applications is common that middle management to be reluctant about to give full access to final users for a variety of reasons, so is very likely that you as a requirements engineer, business analyst, product owner, etc., end up dealing with supervisors and managers of the users on what you’re interested in.

    We must be very careful when we dealing with those proxies, especially in public institutions that are very bureaucratic, because this they tend to fall in bad practices that try to minimize, dissimulate or hide during their process and operations.

    On other occasions, the users’ supervisors intercede and want to represent the role of a user because they think they know more than the real users. But usually, the managers or supervisors have different usage pattern. You should be skilled enough to “turn around” that proxy and reach the final users as much as you can without offending the supervisor. In the section, What to do without users (or almost)? you can read what to do in those cases.

    Development managers, development supervisors, development directors, development leaders and similar

    This type of proxy is one the worst options unless you are writing software specifically for this type of user. Even when the intentions of this type of user sometimes are good, it’s likely this type of leader has his/her own interests and prioritize in a different way the requirements or user stories than a final user would.

    This happens because this role tends to accelerate the introduction of new technologies, or in the worst case scenario, when there is too much technical debt or a disorganized operation, s/he will try to reduce her/his workload at the slightest opportunity.

    Finally, the development managers usually don’t have experience as final users of the solution that is being built and they aren’t domain experts of interest. If a development supervisor es a real final user then you can consider him an appropriate domain expert, otherwise I advise you to avoid using her/him as a proxy if possible.

    People involved in sales

    The danger of use people involved in sales as proxies is that they usually tend to want to close a sale quickly and no matter what, which leads to a distorted vision about how a product should be built.

    If the person in sales, lost the last sale due the lack of a specific characteristic, you can be sure that those people in sales instantly will include as a high priority requirement that characteristic or functionality. Another common situation is people in sales, according to the potential sale earning or commission tends to promise too much even with a small knowledge about other domains, with short-term benefit vision.

    A company that places too much emphasis on lost sales or short-term profits may lose track of its vision and long-term strategies.

    However, the people in sales can be a great conduct to reach final users and we should use them in that way. Ask to them introduce you to customers, join them in sales visits, in sales shows and promotion events, learn about how the products or services of your organization are exhibited and then talk to the users.

    Domain experts

    The domain experts are those who give us what we call experts’ domain and can be very important due to the knowledge that they have in the field of our product. Of course, some domains are more complex than others.

     

    The domain experts can be great resources, but their usefulness is very dependent on whether they are current users or former users of the type of solution that we are creating. Knowing this we must be aware that this kind of proxies can make us create products aimed to their domain level, and if we are not careful we could end creating a too much complex software for the real users level.

    Marketing groups

    People or groups focused on marketing tend to focus more on the market or in niches themselves, rather than on individual users, so the result is that they concentrate more on quantities of functionalities than on the quality of them.

    But do not dismiss our marketing friends, in many cases, they can provide us with valuable high-level information that can help us to establish relative priorities, but we shouldn’t expect a detailed vision for our requirements or user stories.

    Former users

    A former user can be a great proxy if their experience is recent. However, as with other proxies, we must be careful and consider that the objectives and incentives of our proxy are aligned with those of the current final user.

    Customers

    Customers are the ones who make the purchasing decision; they aren’t necessarily final users of the product. It’s important to consider the wishes of your customers because they, not your users, are the ones who sign the check to buy the solution unless of course, the final users and the clients are the same people.

    The features of a product like this should be enough so that the end users do not shout too loudly; but they must also be those that attract the customer who makes the purchasing decision.

    Trainers and technical support

    Trainers and technical support personnel may seem like logical options to use as user proxies. They spend their days talking to real users, so they must surely know what the users themselves want, right? Well, unfortunately, if you use a trainer as your user proxy, you will end up with a system, that is, easy to train.

    Similarly, if you use someone from technical support, you will end up with a system that is very compatible and easy for supporting. For example, someone from technical support can assign a low priority to advanced features that he anticipates will increase support work.

    While ease of training and compatibility are good objectives, it’s most likely that they aren’t what a true final user would prioritize.

    System analysts and business analysts

    Many business analysts and systems analysts make good user proxies because they have a foot in the world of technology and the other one in the processes and operation domain. An analyst who can balance this background and who strives to talk to real users is often an excellent proxy user.

    A problem that some analysts present is that they prefer to think about a detected problem instead of research about it to solve it. Another problem that I’ve encountered occasionally is they tend to spend too much time on project’s upfront tasks.

    What to do without users (or almost)?

    When access to users is limited

    When the team needs it to work with a proxy, it’s important to be very quick and establish with the sponsors, the proxy and management with sufficient authority, the fact that it’s necessary to establish a small “advanced post” group formed by real users, in order to evaluate any initiative, theory or assumption, and achieve validated knowledge as soon as possible.

    Be efficient and transparent by scheduling constant meetings of maximum established duration and at a constant pace to facilitate meetings and minimize external obstacles, making it clear from the beginning that the objective is to identify, write and prioritize user stories or requirements.

    If there are really no users available

    When a user is not really available and must use a user proxy, a valuable technique is using more than one user proxy. This helps to reduce the likelihood of building a system that only satisfies one person’s needs. When you use more than one user proxy, make sure use different types of proxy. For example, combine a domain expert with someone from marketing instead of using two domain experts.

    If you are developing software that competes with other commercial products, you can use the competitive products as a source of some user stories or requirements. What features of the products of the competition are mentioned in the reviews? What features are discussed in the online newsgroups? Are the features discussed because they are too complex to use or because they are very useful?

     

    Another technique that you can use when you’re working with a user proxy instead of real users, is releasing the product as soon as possible. Even whether you call it preliminary version, beta, early, etc., try to put it in the hand of the users as soon as possible and identify inconsistencies between the user proxy thoughts and the actual real users, so you also get validated knowledge. Even better, once the software is in the hand of one or more of the first users, you now have a communications path to these real users and can use that to talk with them about upcoming features.

    Can you do it your self?

    When you can’t find or access to a real user, don’t fall into the trap of thinking you know the users’ mind and you don’t need or you can ignore a user proxy. Even if each type of user proxy has some kind of inconvenience that makes her/him less desirable than a real user, most developers have even more deficiencies to pretend to be a real user.

    In general, developers don’t have marketing knowledge that allows them to understand the features’ relative value, they don’t have the same amount of contact with the customer as the salespeople, they are not domain experts, etc.

    Do you know another type of user? Do you have a different opinion about the proxies presented here?

    *Sorry about my English, I’m not natural speaker :p. Don’t be grumpy and help me to improve 😀

    Other links of interest:

    Agile’s Origins and Values
    The Agile Team Approach

    If you want to know more, these are some recommended books:

    Any help is welcome to help us keeping this effort alive! PayPal Account BTC (Bech32): bc1qx6f8nczr5ram6d57svlnsfmk5mhu6lsr9q7mxw BTC: 1DDcWbphm1bKMvWruotNKLSM8ypVaHg5Nv ETH: 0x58D137fb142D946bCD815f0ded0fa3b3fE5AB3BF

    No Comment
  • Upload A File With HTML5 / Subir un archivo con HTML5
    CSS3 / Desarrollo / Development / Destacadas / Featured / HTML5 / JavaScript / Software

    Upload A File With HTML5 (XMLHttpRequest)
    flashw

    Upload A File With HTML5 / Subir un archivo con HTML5

    The XMLHttpRequest object

    The XMLHttpRequest object has been updated several times since was defined as the WHATWG’s HTML effort using Microsoft technology; then we had the original XMLHttpRequest Level 1 specification as part of W3C, we also had the XMLHttpRequest Level 2 updated specification, and now we have the last version of this object known as XMLHttpRequest Living Specification. We can summarize its advantages in the following points:

    • Allows upload and download files as stream bytes, large binaries (BLOBs) or data forms
    • It has event handlers for progress, errors, abortion, start, and end of operations
    • Cross-domain capabilities (CORS)
    • New type for JSON responses
    • Is a fundamental part of the HTML5 File API specification

    It’s important to emphasize that before HTML5 and the latest versions of XMLHttpRequest object it was required to resort to server-side technology in order to able to perform an uploading file operation, that is, it wasn’t possible to upload a file natively from the client side. Technologies as AJAX and Flash did their own effort but with serious limitations, so XMLHttpRequest comes to cover this old problem in a big way. There are other additional features that come with XMLHttpRequest, if you want to know more you can resort to the official specification.

    Starting

    The first thing we’ll do is to define the user interface for this small implementation starting with the HTML tags, the code is very simple and only includes some form elements, and some div tags that are only used to give a better presentation using CSS3. I won’t analyze in this post anything related to the used cascade style sheets since is not something really necessary for the operation of this example.

    <!DOCTYPE html>
<html>
    <head>
        <title>Upload File</title>
        <meta charset="iso-8859-1" />
    </head>
    <body>
    <div id="wrap">
       <div class="field">
           <ul class="options">
              <li><input type="file" id="myfile" name="myfile" class="rm-input" onchange="selectedFile();"/></li>
              <li><div id="fileSize"></div></li>
              <li><div id="fileType"></div></li>
              <li><input type="button" value="Subir Archivo" onClick="uploadFile()" class="rm-button" /></li>
           </ul>
       </div>
       <progress id="progressBar" value="0" max="100" class="rm-progress"></progress>
       <div id="percentageCalc"></div>
    </div>
    </body>
</html>
    The previous code explains itself, but let’s summarize what is in there:
    • A file-type input which will be used to select the file to be uploaded
    • A div which will be used to print the size of the selected file
    • A div which will be used to print the MIME type of the selected file
    • A button which will fire the uploading process for the selected file
    • A progress bar to indicate the uploading process progress of the selected file
    • Finally, a div where the progress will be shown in a percentage format

    The selectedFile() function

    Each time you select a file using the file element, you also trigger the onchange event which calls the selectedFile() function. In this function very interesting things happen, to start, a reference to a file array instantiated by the HTML5 object FileList is done, the objects that we get as members of FileList are File objects. In this case, we’ll get the size and type properties from the gotten File object.
    Using the information provided by the size property, the size of the selected file is calculated and shown in megabytes or kilobytes within the function. With the type property, the MIME type of the selected files is gotten and showed in the corresponding div.
    function selectedFile() {
var archivoSeleccionado = document.getElementById("myfile");
var file = archivoSeleccionado.files[0];
   if (file) {
       var fileSize = 0;
       if (file.size > 1048576)
          fileSize = (Math.round(file.size * 100 / 1048576) / 100).toString() + ' MB';
       else
          fileSize = (Math.round(file.size * 100 / 1024) / 100).toString() + ' Kb';

       var divfileSize = document.getElementById('fileSize');
       var divfileType = document.getElementById('fileType');
       divfileSize.innerHTML = 'Tamaño: ' + fileSize;
       divfileType.innerHTML = 'Tipo: ' + file.type;

    }
}

    The uploadFile() function

    Esta es la función que hace un mayor uso de las nuevas posibilidades de XMLHttpRequest , y es la que se encargará de disparar el proceso principal del lado cliente.

    function uploadFile(){
 //var url = "/ReadMoveWebServices/WSUploadFile.asmx/UploadFile";
 var url = "/ReadMoveWebSite/UploadMinimal.aspx";
 var archivoSeleccionado = document.getElementById("myfile");
 var file = archivoSeleccionado.files[0];
 var fd = new FormData();
 fd.append("archivo", file);
 var xmlHTTP = new XMLHttpRequest();
 //xmlHTTP.upload.addEventListener("loadstart", loadStartFunction, false);
 xmlHTTP.upload.addEventListener("progress", progressFunction, false);
 xmlHTTP.addEventListener("load", transferCompleteFunction, false);
 xmlHTTP.addEventListener("error", uploadFailed, false);
 xmlHTTP.addEventListener("abort", uploadCanceled, false);
 xmlHTTP.open("POST", url, true);
 //xmlHTTP.setRequestHeader('book_id','10');
 xmlHTTP.send(fd);
}
    At the beginning, we have the variable url that we’ll use to indicate where is the page o web service which is going to receive the request from this page to do the proper process on server side. Immediately like in the selectedFile() function, a reference to the gotten File object member is also done.
    In the fourth line, there is something new and very useful, that is the FormData object, this object allows to instantiate a web form via JavaScript, that is, is like you put an HTML form using tags, or you can refer to an already existing one assigning it to a FormData object. No doubt this is really helpful since means now you can create a web form y alter the sending values dynamically. To append values to, either instantiated or referenced web form with FormData, use the append(file, object) method, this way in the fifth line our File object is added with the file name.
    This is the code of the function that covers what was just stated:
    //var url = "/ReadMoveWebServices/WSUploadFile.asmx/UploadFile";
var url = "/ReadMoveWebSite/UploadMinimal.aspx";
var archivoSeleccionado = document.getElementById("myfile");
var file = archivoSeleccionado.files[0];
var fd = new FormData();
fd.append("archivo", file);

    Event handlers

    Continuing with the rest of the function, we can observe that the XMLHttpRequest object is finally instantiated and is assigned to the xmlHTTP variable, and then we proceed to the next novelty, I mean the possibility of creating new events which are part of XMLHttpRequest thanks to the upload object. The added events for this particular case are:
    • loadstart. Is triggered when the uploading file process initiates.
    • progress. Is triggered each time there is an advance in the file uploading process.
    • load. Is triggered when the transfer is complete successfully.
    • error. Is triggered when the transfer fails
    • abort. Is triggered when the user/developer interrupts the process.
    These aren’t the only available events, check the official specification for more information.
    The event handlers are declared in the following code:
    var xmlHTTP= new XMLHttpRequest();
//xmlHTTP.upload.addEventListener("loadstart", loadStartFunction, false);
xmlHTTP.upload.addEventListener("progress", progressFunction, false);
xmlHTTP.addEventListener("load", transferCompleteFunction, false);
xmlHTTP.addEventListener("error", uploadFailed, false);
xmlHTTP.addEventListener("abort", uploadCanceled, false);

    The triggered events functions are the following:

    function progressFunction(evt){
    var progressBar = document.getElementById("progressBar");
    var percentageDiv = document.getElementById("percentageCalc");
    if (evt.lengthComputable) {
        progressBar.max = evt.total;
        progressBar.value = evt.loaded;
        percentageDiv.innerHTML = Math.round(evt.loaded / evt.total * 100) + "%";
    }
}
 
function loadStartFunction(evt){
    alert('Comenzando a subir el archivo');
}
 
function transferCompleteFunction(evt){
    alert('Transferencia completa');
    var progressBar = document.getElementById("progressBar");
    var percentageDiv = document.getElementById("percentageCalc");
    progressBar.value = 100;
    percentageDiv.innerHTML = "100%";
}
 
function uploadFailed(evt) {
    alert("Hubo un error al subir el archivo.");
}
 
function uploadCanceled(evt) {
    alert("La operación se canceló o la conexión fue interrunpida.");
}

    ProgressFunction() updates the progress bar and percentage which indicate in a graphical and numerical way the process progress, the rest of the functions only display the proper message for each case.

    Commented code

    If you have observed the code you probably noticed some commented lines, this is because this is just the base code to create something a little bit more complex, but I decided to leave those lines because maybe can be useful for someone:

    //var url = "/ReadMoveWebServices/WSUploadFile.asmx/UploadFile";

    The previous line of code is a call to a .Net HTTP service instead of a page. Here is where you should call your own server-side implementation.

    //xmlHTTP.upload.addEventListener("loadstart", loadStartFunction, false);

    This line calls a function that shows a message when the process starts. I commented this line after I executed the code several times because was annoying.

    The completo code

    This is how the complete implementation of the code looks:

    <!DOCTYPE html>
<html>
    <head>
        <title>Upload File</title>
        <meta charset="iso-8859-1" />
                                    <link rel="stylesheet" type="text/css" href="estilosUploadFile.css" />
        <script type="text/javascript">
 
              function selectedFile() {
                var archivoSeleccionado = document.getElementById("myfile");
                var file = archivoSeleccionado.files[0];
                if (file) {
                    var fileSize = 0;
                    if (file.size > 1048576)
                        fileSize = (Math.round(file.size * 100 / 1048576) / 100).toString() + ' MB';
                    else
                        fileSize = (Math.round(file.size * 100 / 1024) / 100).toString() + ' Kb';
 
                    var divfileSize = document.getElementById('fileSize');
                    var divfileType = document.getElementById('fileType');
                    divfileSize.innerHTML = 'Tamaño: ' + fileSize;
                    divfileType.innerHTML = 'Tipo: ' + file.type;
 
                }
              }     
 
            function uploadFile(){
                //var url = "http://localhost/ReadMoveWebServices/WSUploadFile.asmx?op=UploadFile";
                var url = "/ReadMoveWebServices/WSUploadFile.asmx/UploadFile";
                var archivoSeleccionado = document.getElementById("myfile");
                var file = archivoSeleccionado.files[0];
                var fd = new FormData();
                fd.append("archivo", file);
                var xmlHTTP= new XMLHttpRequest();
                //xmlHTTP.upload.addEventListener("loadstart", loadStartFunction, false);
                xmlHTTP.upload.addEventListener("progress", progressFunction, false);
                xmlHTTP.addEventListener("load", transferCompleteFunction, false);
                xmlHTTP.addEventListener("error", uploadFailed, false);
                xmlHTTP.addEventListener("abort", uploadCanceled, false);
                xmlHTTP.open("POST", url, true);
                //xmlHTTP.setRequestHeader('book_id','10');
                xmlHTTP.send(fd);
            }       
 
            function progressFunction(evt){
                var progressBar = document.getElementById("progressBar");
                var percentageDiv = document.getElementById("percentageCalc");
                if (evt.lengthComputable) {
                    progressBar.max = evt.total;
                    progressBar.value = evt.loaded;
                    percentageDiv.innerHTML = Math.round(evt.loaded / evt.total * 100) + "%";
                }
            }
 
            function loadStartFunction(evt){
                alert('Comenzando a subir el archivo');
            }
            function transferCompleteFunction(evt){
                alert('Transferencia completa');
                var progressBar = document.getElementById("progressBar");
                var percentageDiv = document.getElementById("percentageCalc");
                progressBar.value = 100;
                percentageDiv.innerHTML = "100%";
            }   
 
            function uploadFailed(evt) {
                alert("Hubo un error al subir el archivo.");
            }
 
            function uploadCanceled(evt) {
                alert("La operación se canceló o la conexión fue interrunpida.");
            }
 
        </script>
    </head>
    <body>
        <div id="wrap">
            <div class="field">
                <ul class="options">
                    <li>
                        <input type="file" id="myfile" name="myfile" class="rm-input" onchange="selectedFile();"/>
                    </li>
                    <li>
                        <div id="fileSize"></div></li>
                    <li>
                        <div id="fileType"></div></li>
                    <li>
                        <input type="button" value="Subir Archivo" onClick="uploadFile()" class="rm-button" /></li>
                </ul>
            </div>
            <progress id="progressBar" value="0" max="100" class="rm-progress"></progress>
            <div id="percentageCalc"></div>
        </div>
    </body>
</html>

    I’m not describing the CSS3 code because is irrelevant in terms of functionality, but I share an image that shows how it looks the implementation in the browser and the link to the CSS3 estilosUploadFile.zip.

    I’m also sharing the original HTTP service that I used to test this example -the server-side code, backend file or any name that you prefer 😃- but this won’t be very useful for you unless you use the exact same stack that I was using at the moment- in other words, if you are the kind of person who just wants to copy and paste….hehehe well….maybe you’re not ready for this yet. Here is the file WSUploadFile.zip

    Sorry about my English I’m not a natural speaker (don’t be grumpy, help me to improve).

    This is all for now folks, I hope this can be useful for you.

    Here some books that can help you in your HTML5 journey:

    4 Comments
  • HTML unknow
    CSS3 / Desarrollo / Development / Destacadas / Featured / Diseño Web / HTML5 / Ideas / Programación / Programming / Software

    HTML5, HTML Living, HTML .Next, y ¿HTML6?
    flashw

    HTML5, HTML Living, HTML .Next, y ¿HTML6?

    Durante las charlas que he tenido oportunidad de dar ante una audiencia, en algún blog o bien por alguna red social me he topado con algunos planteamientos que hacen referencias a HTML6 (OMG!!!!) o bien a HTML Living y/o HTML .Next, a que HTML5 ya caducó (OMG again!!!) y otra serie de afirmaciones o preguntas que van de lo veraz a lo absurdo, pasando por verdades a medias. Para aclarar un poco la situación he decidido hacer esta entrada y describir lo que pasa con HTML5, HTML Living, HTML .Next, y HTML6.

    Algo de contexto.

    HTML5 ha sido una exitosa tecnología apoyada por muchas organizaciones con diferentes perfiles e intereses relacionados de diferente forma con el desarrollo web, como son empresas, universidades, organizaciones civiles,etc., pero el grupo más representativo y con mayor historia aunque no siempre el más influyente, ha sido el World Wide Web Consortium (W3C) el cual ha generado muchas recomendaciones para la world wide web, estas recomendaciones van dirigidas mayormente al desarrollo del HTML y tecnologías conexas. Sin embargo la W3C no ha sido el único grupo haciendo recomendaciones y trabajando constantemente para evolucionar el HTML y tecnologías relacionadas desde su perspectiva, otro de estos grupos el cual sin duda obtuvo gran relevancia es el Web Hypertext Application Technology Working Group (WAHTWG). Ambos grupos han sido importantes gracias a sus iniciativas y a sus miembros, los cuales incluyen entre muchos otros a organizaciones tan influyentes como Google, Microsoft, Apple, Adobe, Mozilla Fundation y Opera Software.

    En el 2007 ambos grupos deciden unir fuerza y utilizar la especificación HTML propuesta por WAHTWG como punto de partida para continuar con el desarrollo de la especificación HTML, lo cual se conoció eventualmente como HTML5. Dado esto, todas las nuevas especificaciones se comenzaron a publicar de manera oficial por me dio de W3C, sin embargo el principal y único editor oficial con la facultad de publicación fue el miembro de WAHTWG, Ian Hickson quien a su vez trabaja con Google.

    El ascenso de HTML5.

    Gracias al esfuerzo conjunto de ambas organizaciones y sus miembros HTML5 comenzó a hacerse popular, adquiriendo muchísima más relevancia extra gracias el exponencial crecimiento de dispositivos móviles y las ventajas técnicas que representa HTML5 sobre las alternativas dominantes hasta el momento. El punto quizá más relevante para la popularidad de HTML5 surgió gracias a las polémicas declaraciones del entonces CEO de Apple Steve Jobs, quien puso de manifiesto las desventajas de desarrollar para los nuevos dispositivos utilizando el entonces estándar de facto en la realización de implementaciones de rico contenido gráfico, Flash (en internet80 ya dedicamos un a larga perodata a este tema algunas entradas).

    Desde luego un factor esencial para el éxito de HTML5 es que W3C incluye entre sus miembros  a aquellos que también son los fabricantes de los principales navegadores, y que estos tratando de apoyar la nueva especificación dieron soporte a HTML5 haciendo que Chrome, Explorer, Safari, Mozilla y Opera lo soportaran aunque con diferentes grados de avance en su implementación. Todas estas circunstancias favorecieron a que HTML5 pudiera tener nombre, presencia, crecimiento e incluso logotipo que lo identifica ante propios y extraños.

    El drama.

    Desafortunadamente no todo es felicidad, como sucede en todas las organizaciones (creo) existe desacuerdos  y complicaciones. Desde el 2011 se escapaba uno que otro rumor que giraba en torno a diferencias entre W3C y WAHTWG, sin embargo el punto de quiebre es cuando efectivamente estas organizaciones deciden separarse a mediados del 2012 e Ian Hickson publica una carta abierta donde explica el status de la relación entre ambos grupos.

     

    Pero ¿que pasó en realidad? bueno pues todo son versiones de diferentes fuentes y no puedo corroborarlo todo, pero si me permite resumiré todo lo que he leído en 3 puntos persistentes en la mayor parte de las fuentes consultadas:

    • W3C está más preocupado por la estandarización de HTML mientras que WAHTWG está más preocupado por la implementación de nuevas funcionalidades para HTML. Esto significa que la W3C está priorizando más el orden y la consistencia de la especificación para que los fabricantes de navegadores, desarrolladores y otros interesados cuenten con una referencia más precisa y mucho más compatible, mientras que WAHTWG considera que lo más importante es dar más y mejores características innovadoras a HTML para ampliar la gama de posibilidades en la creación de todo tipo implementaciones.
    • Descontento del editor. Ian Hickson es una persona que sin duda se ha hecho de un nombre en la industria y comunidad web ya que ha trabajado para diferentes empresas de mucho peso y ha colaborado con el desarrollo de varias especificaciones importantes, actualmente como empleado de Google y anteriormente como único editor oficial de la especificación HTML5 , parte de su trabajo consistía en analizar, corregir y conciliar las diferencias de las propuestas técnicas de la W3C y WAHTWG con respecto a la especificación, lo cual lo llevó eventualmente manifestar su inconformidad con las implicaciones y diferencias entre las propuestas y en tener que unificarlas. Otro factor de desacuerdo es la visión de Hickson acerca de irrelevancia de usar versiones en la especificación HTML, ya que desde su punto de vista no debería existir HTML4, HTML5 , HTML6, etc., sino simplemente HTML con su intrínsica evolución.
    • Intereses y DRM. Hasta el día de hoy existe muchas críticas hacia la W3C, ya que varios grupos argumentan que la insistencia de este grupo por estandarizar HTML obedece principalmente al interés de las empresas más grandes que son miembros de la organización ya que buscan maneras de patentar y hacer desarrollos cerrados, lo que incluye la posibilidad de integrar DRM a la especificación. Algunas de las voces que suman ha estas críticas son la Free Software Foundation, Web Content Accessibility Guidelines Working Group (WCAGWG), la propia WAHTWG y su miembro Ian Hickson. Pese a todo la recomendación para DRM en HTML5 es hoy ya una realidad que fue publicada en Septiembre del 2017 como la recomendación Encrypted Media Extensions (EME), por lo que pronto verá a Netflix, HULU, Amanzon, etc. echando mando de esto para ofrecer sus servicios.

    Las consecuencias…HTML Living y HTML .Next

    La especificación HTML5 ha tenido diferentes “deadlines”…2011, 2012, 2014, 2022, todos estos años han sido mencionados para terminar la especificación, pero la verdad sea dicha, nadie sabe a ciencia cierta cual será la fecha final o la versión buena, tampoco si el nombre se mantendrá o cambiará, ni siquiera todas las agrupaciones mencionadas, ya que todo obedece a muchos factores incluyendo desacuerdos y reconciliaciones (sí, cual telenovela mexicana de adolecentes dramáticos y despechad@s).

    W3C extraoficialmente hizo una especie de corte en 2014 para dejar en una especie “cierre de etapa” a la especificación HTML5 y desde ahí comenzarón a usar el término HTML .Next, HTML Next (sin el punto), HTML /Next o HTML5 Next. Por su parte,  WAHTWG ha comenzado con lo que llama la especificación HTML Living para dar nombre a los avances de sus especificaciones.

    ¿HTML6?

    Permítame aclaro esto de una vez por todas, hoy NO EXISTE ALGO QUE SE LLAME HTML6, lo que a algunas personas les ha dado por llamar HTML6 es precisamente al conjunto de los conceptos HTML Living y HTML .Next, los cuales cada navegador soporta a discreción, HTML6 NO es un nombre oficial ni nada por el estilo, mañana tal vez, pero hoy no lo es.

    ¿Cómo nos afecta esto a los desarrolladores?

    !No lo sabemos!, antes de que cunda el pánico y corra a buscar libros y manuales de HTML Living y HTML .Next, la realidad es que la última palabra la tendrán los fabricantes de navegadores que son los que decidirán a que especificación apoyar en su momento, pero tenga presente que las cosas en el mundo de la tecnología cambian muy rápido y a veces de manera inesperada, y que las empresas y las organizaciones son finalmente dirigidas por personas que pueden cambiar de opinión en cualquier momento, ¿alguien se acuerda del choque Blu-Ray VS HD-DVD, donde supuestamente ganó el BR? (aunque el verdadero ganador fue el streaming). Por otro lado, si quiere saber el peor de los casos, este sería que los desarrolladores tuviéramos que lidiar con varias especificaciones HTML.

    ¿Debería dejar de aprender HTML5?

    NOOO!! no cometa ese error, HTML5 sigue vigente y avanzando, hoy en día la realidad es que las especificaciones HTML Living y HTML .Next más populares terminan ciendo integradas a la especificación de la W3C, es decir, ambas especificaciones parten evolucionan y regresan a la especificación de HTML5, ya que los navegadores usan todo lo que perciban como mejora a pesar de los desacuerdos, de manera que es todo lo contrario, hay que continuar aprendiendo HTML5 .

    Para saber más:
    Can I use (una lista detallada de características HTML5 y su estado de implementación en la mayoría de los navegadores de escritorio y dispositivos móviles)
    The Burning Edge (developments in nightly builds for Firefox)
    Algunos libros recomendables:
    No Comment
  • Google Pay
    Destacadas / Featured / Póntelo / Put it on

    Google Wallet y Android Pay Son Uno, son Google Pay
    flashw

    En el 2011 me quejaba de la fragmentación del sistema de de pago Google Wallet y del fail que sería el solo intertar implementarlo en América Latina. Pero en las recientes semanas (Enero 2018), Google anunció que ahora todos sus diferentes servicios de pago, incluidos Android Pay y Google Wallet, se combinan en un servicio unificado, simplemente llamado Google Pay.

     

    Con el nuevo sistema, la información de pago queda guardada en su cuenta de Google (no en su cuenta de Google Store y su celular como antes) y estará disponible en todos los lugares donde use productos de Google: en Chrome para compras web, en YouTube para renovar sus suscripciones, en aplicaciones en la Android Play Store para compras integradas y en tiendas minoristas con tecnología de pagos NFC.

    Según Google, aplicaciones como Airbnb, Dice, Fandango, HungryHouse e Instacart ya son compatibles con Google Pay, con más sitios y tiendas listos para lanzarse como parte de este ecosistema de pagos en las próximas semanas.

    Al no tener que registrarse en un nuevo servicio sólo para el celular como ocurría antes, creo que este servicio tiene una mejor chance de colocarse en regiones difíciles (por temas de robos e inseguridad) ya que el usuario puede gestionar su cuenta con mayor inmediatez desde otro dispositivo a su cuenta de manera centralizada para gestionar su servicio.

     

    Para el usuario parece que no ha muchos cambios en lo procesos de sincronizacion de tarjetas y cuentas. Donde no está claro, e que si Google dice que Google Pay está disponible ahora “en Airbnb, Dice, Fandango, HungryHouse, Instacart ya soportan la plataforma y otras se sumarán”. ¿Eso significa que las empresas necesitan hacer algo para soportar el nuevo servicio? ¿Hay un nuevo servicio de soporte que debo contactar si mi taquería quiere ofrecer esta opción de pago? (sí soy de México :p).

     Supongo que pronto tendremos las respuesas a esta y otras preguntas. Pero por lo pronto ya no habrá que registrarse para un nuevo servicio y tenemos un logo nuevesito 😀
    No Comment