Parece que al fin y al cabo tenemos competencia open source:
http://www.taskjuggler.org/manual-git/features_and_highlights.html
miércoles, diciembre 16, 2009
Sketches, prototypes, documentation, and Microsoft Blend
Kevin Silver uses Blend as an excuse to mull over the role of prototyping tools in the early design process and its communication to development teams.
It links to Parti & The Design Sandwich for a way to derive design criteria for a particular project.
Some article higlights:
Sketches and prototypes serve different purposes, even if they are built with the same tools. Take care not to create a prototype while sketching is still needed.
Design documentation must tell the complete story. Sketches and prototypes don't do that, but are good starting points.
Documentation is needed even if it's an afterthought:
It links to Parti & The Design Sandwich for a way to derive design criteria for a particular project.
Some article higlights:
Sketches and prototypes serve different purposes, even if they are built with the same tools. Take care not to create a prototype while sketching is still needed.
Buxton makes a succinct distinction between sketching and prototyping. Sketches are noncommittal and tentative. They let you suggest, explore, and question. Conversely, prototypes are specific depictions that allow you to describe, refine, and test your design solutions. So, prototypes are refined demonstrations of your design intent.
Design documentation must tell the complete story. Sketches and prototypes don't do that, but are good starting points.
To create an effective demonstration of your design intent, you must consider your audience. I have no problem showing a hand-drawn, static sketch to a design-savvy crowd, who can easily see and understand the invisible behavior with little explanation. However, I am more inclined to show a digital, dynamic sketch or prototype to a mixed room.
Documentation is needed even if it's an afterthought:
Dave points out that various departments within your organization—like quality assurance, legal, or compliance—might need to be able to review the deliverables you create to understand parts of a product. Dan Brown reminds us that we also have to consider other documentation needs like guidelines, standards, and pattern libraries when creating our final deliverables.
lunes, diciembre 14, 2009
Dimensions and principles of design
Dimensions of design/Against ahistoricity « Adam Greenfield’s Speedbird
How does design affect choice?
The design of a place affects the choices people can make, at many levels:
- it affects where people can go and where they cannot: the quality we shall call permeability.
- it affects the range of uses available to people: the quality we shall call variety.
- it affects how easily people can understand what opportunities it offers: the quality we shall call legibility.
- it affects the degree to which people can use a given place for different purposes: the quality we shall call robustness.
- it affects whether the detailed appearance of the place makes people aware of the choices available: the quality we shall call visual appropriateness.
- it affects people’s choice of sensory experiences: the quality we shall call richness.
- it affects the extent to which people can put their own stamp on a place: we shall call this personalization.
Ten principles for good design
miércoles, diciembre 09, 2009
Firefox extensions - the easy way
Mozilla Labs Jetpack | Exploring new ways to extend and personalize the Web
Jetpack is a Mozilla Labs project that enables anyone who knows HTML, CSS, and JavaScript to create powerful Firefox add-ons. Our goal is to allow anyone who can build a Web site to participate in making the Web a better place to work, communicate and play.
The Usability Methods Toolbox
The Usability Methods Toolbox
Glossary and resources of usability methodsmiércoles, noviembre 25, 2009
Monads explained to imperative programmers
(See also: answers to this slashdot comment)
I come from an imperative background myself. Let's see if my explanation of I/O and state handling in pure funtional languages, based on imperative metaphors, makes more sense for you. Please let me know if you find the following useful, I might expand it to my own personal "monad tutorial" (this seems to be a tradition when learning Haskell).
- Monads are program structures that represent processes (and one particular kind of process for each kind of monad), but in a different way than functions represent processes. Actually I think of monads as little virtual machines embedded in the functional language, that encapsulate all the boring bookkeeping and boilerplate that must be done in any program alongside the interesting business logic.
- A monad is used as a framework: you will program a sequence (or 'pipeline') of instructions in an imperative style (the do-block), using some vocabulary defined by the monad (the monadic type constructor, and return and bind operators). These blocks can then be instantiated and passed to the monad, to be executed according to the control logic programmed in the monad definition. Side effects during the sequence of actions in the do-block are instructions evaluated outside the do-block, but inside the (functional) monad code.
- As for the I/O and state handling, remember that you have IO and State monads, and that each monad represent one kind of computation. IO represents *processes that interact with the real world*, and state monads represent *processes that depend on an internal state, that changes as the process evolves*. The trick to use them in a pure functional language is that the actual side-effect is not spread all over your programming language, it's encapsulated inside the monad definition.
- The good thing of all this programming style is that you can actually *do* imperative programming, but in a much more controlled manner: instead of relying on the "generic VM" embedded in your imperative programming language (with all its risk of incorrect side-effects) you can execute it in your controled micro-VM defined by the monad. In that way, the only side-effects allowed inside the do-block are those that you enable yourself. Monads work as aspects in OOP: they represent one particular kind of unrelated logic (such as exceptions, concurrency...) that must be processed in the background of your main computation, and can alter its control flow. If you want your block to handle several aspects at once, you can always wrap several monads one inside another with monad transformers.
For example, the List type when used as a monad represents a computation which can return more than one result (or less than one, which is the empty list). Inside a do-block where one instruction has a List result, this means that the following instruction will get executed *once for each element in the list*, with its input parameter being each element. This is used for example in list comprehensions:
do { x <- [1..3] ; y <- [1..x] ; return (x,y) } ---> [ (1,1) , (2,1) , (2,2) , (3,1) , (3,2) , (3,3) ]
Is Haskell a "pure functional" language?
1) Haskell is pure functional, but that means "everything can be described as functions, even side-effects". Side effects happen inside do-blocks during the monad pipeline evaluation, but are side-effects only with respect to the do-block, not with respect to the language (the language views them as function calls over the monadic values).
2) Thanks to monads, you can embed side-effects to the do-block inside the IO monad (whose low-level system calls are then defined as a language primitive embedded in the read/write functions, the same way as it's done in imperative languages with read/write subroutines). If you expand the syntactic sugar of the do-block it gets transformed into a series of function calls, in which the monad state is one input parameter and the new state is in the result. In order to understand how this works, I'm affraid you should also learn about continuations, which complement monads in order to describe imperative execution in terms of functions.
Are side-effects part of the functional language, or something external to it?
We must get a bit philosophical here, in the sense that it depends on how you define "computation". It's been demostrated somewhere that imperative and functional programming are mathematically equivalent (i.e. both have the power of Turing machines). This means that you can represent functional languages using an imperative program, but also that you can represent imperative languages using a functional program.
In fact this is the trick used by Turing himself to solve the decision problem, even before computers existed! Mathematics is purely side-effect free, and yet it's used to describe all possible computations. There's a branch of it called "temporal logic" that is related to how continuations and the State monad work. Logic assertions are universally true, but you can create assertions about the world in a particular state that are not true for other states. By passing the transformed state from one logic expression to the next (or from one function to the next), you can represent state changes. Similarly, continuations are functions that represent *all the instructions left to be executed in the program*, and take as a parameter the current program state.
The one style you use is up to your personal preference, really. Modern Haskell is showing that we could switch all the imperative theoretical basis of programming as were defined during the 40's and 50's to a functional basis, and thus retaining all that can be done with state changes while gaining the reasoning properties of functional.
I come from an imperative background myself. Let's see if my explanation of I/O and state handling in pure funtional languages, based on imperative metaphors, makes more sense for you. Please let me know if you find the following useful, I might expand it to my own personal "monad tutorial" (this seems to be a tradition when learning Haskell).
- Monads are program structures that represent processes (and one particular kind of process for each kind of monad), but in a different way than functions represent processes. Actually I think of monads as little virtual machines embedded in the functional language, that encapsulate all the boring bookkeeping and boilerplate that must be done in any program alongside the interesting business logic.
- A monad is used as a framework: you will program a sequence (or 'pipeline') of instructions in an imperative style (the do-block), using some vocabulary defined by the monad (the monadic type constructor, and return and bind operators). These blocks can then be instantiated and passed to the monad, to be executed according to the control logic programmed in the monad definition. Side effects during the sequence of actions in the do-block are instructions evaluated outside the do-block, but inside the (functional) monad code.
- As for the I/O and state handling, remember that you have IO and State monads, and that each monad represent one kind of computation. IO represents *processes that interact with the real world*, and state monads represent *processes that depend on an internal state, that changes as the process evolves*. The trick to use them in a pure functional language is that the actual side-effect is not spread all over your programming language, it's encapsulated inside the monad definition.
- The good thing of all this programming style is that you can actually *do* imperative programming, but in a much more controlled manner: instead of relying on the "generic VM" embedded in your imperative programming language (with all its risk of incorrect side-effects) you can execute it in your controled micro-VM defined by the monad. In that way, the only side-effects allowed inside the do-block are those that you enable yourself. Monads work as aspects in OOP: they represent one particular kind of unrelated logic (such as exceptions, concurrency...) that must be processed in the background of your main computation, and can alter its control flow. If you want your block to handle several aspects at once, you can always wrap several monads one inside another with monad transformers.
For example, the List type when used as a monad represents a computation which can return more than one result (or less than one, which is the empty list). Inside a do-block where one instruction has a List result, this means that the following instruction will get executed *once for each element in the list*, with its input parameter being each element. This is used for example in list comprehensions:
do { x <- [1..3] ; y <- [1..x] ; return (x,y) } ---> [ (1,1) , (2,1) , (2,2) , (3,1) , (3,2) , (3,3) ]
Is Haskell a "pure functional" language?
1) Haskell is pure functional, but that means "everything can be described as functions, even side-effects". Side effects happen inside do-blocks during the monad pipeline evaluation, but are side-effects only with respect to the do-block, not with respect to the language (the language views them as function calls over the monadic values).
2) Thanks to monads, you can embed side-effects to the do-block inside the IO monad (whose low-level system calls are then defined as a language primitive embedded in the read/write functions, the same way as it's done in imperative languages with read/write subroutines). If you expand the syntactic sugar of the do-block it gets transformed into a series of function calls, in which the monad state is one input parameter and the new state is in the result. In order to understand how this works, I'm affraid you should also learn about continuations, which complement monads in order to describe imperative execution in terms of functions.
Are side-effects part of the functional language, or something external to it?
We must get a bit philosophical here, in the sense that it depends on how you define "computation". It's been demostrated somewhere that imperative and functional programming are mathematically equivalent (i.e. both have the power of Turing machines). This means that you can represent functional languages using an imperative program, but also that you can represent imperative languages using a functional program.
In fact this is the trick used by Turing himself to solve the decision problem, even before computers existed! Mathematics is purely side-effect free, and yet it's used to describe all possible computations. There's a branch of it called "temporal logic" that is related to how continuations and the State monad work. Logic assertions are universally true, but you can create assertions about the world in a particular state that are not true for other states. By passing the transformed state from one logic expression to the next (or from one function to the next), you can represent state changes. Similarly, continuations are functions that represent *all the instructions left to be executed in the program*, and take as a parameter the current program state.
The one style you use is up to your personal preference, really. Modern Haskell is showing that we could switch all the imperative theoretical basis of programming as were defined during the 40's and 50's to a functional basis, and thus retaining all that can be done with state changes while gaining the reasoning properties of functional.
lunes, noviembre 23, 2009
Mathematical intuitions and pedagogy
http://betterexplained.com/articles/developing-your-intuition-for-math/
Learning a new math concept requires building an intuition to it through examples, not grasping the simplest mathematical definition upfront.
Learning a new math concept requires building an intuition to it through examples, not grasping the simplest mathematical definition upfront.
User personas vs archetypes vs roles
La diferencia entre un "arquetipo" y un "personaje" de diseño es si se ha basado en investigación de campo real (numérica, medible!).
http://www.virtualfloorspace.com/2009/09/user-archetypes-vs-personas/
A well-researched example persona for web design:
http://www.virtualfloorspace.com/2009/09/using-personas-to-guide-web-design/
A description of roles (focus on separate usage scenarios and performance, not users)
http://www.foruse.com/articles/rolespersonas.pdf
http://www.virtualfloorspace.com/2009/09/user-archetypes-vs-personas/
A well-researched example persona for web design:
http://www.virtualfloorspace.com/2009/09/using-personas-to-guide-web-design/
A description of roles (focus on separate usage scenarios and performance, not users)
http://www.foruse.com/articles/rolespersonas.pdf
miércoles, noviembre 18, 2009
martes, noviembre 17, 2009
RAD prototyping tools
Adobe está diseñando una herramienta para creación de prototipos interactivos en Flash.
Se llama FlashCatalyst. Será un producto comercial, pero de momento la versión beta es pública para obtener feedback.
Otras herramientas RAD prototyping:
Lista: http://www.adaptivepath.com/blog/2009/09/16/rapid-prototyping-tools-revisited/
http://ixedit.com/
https://pidoco.com/en
http://www.balsamiq.com/
http://www.justproto.com/en/
http://protoscript.com/ - comportamientos javascript predefinicos
Se llama FlashCatalyst. Será un producto comercial, pero de momento la versión beta es pública para obtener feedback.
Otras herramientas RAD prototyping:
Lista: http://www.adaptivepath.com/blog/2009/09/16/rapid-prototyping-tools-revisited/
http://ixedit.com/
https://pidoco.com/en
http://www.balsamiq.com/
http://www.justproto.com/en/
http://protoscript.com/ - comportamientos javascript predefinicos
Suscribirse a:
Entradas (Atom)
