Please enable JavaScript.

Coggle requires JavaScript to display documents.

Hyperledger Caliper GUI Design (Resources (Project Lifecycle (Proposal,…

- - - - To post: mentees@lists.hyperledger.org
- - - - Issue Tracking
- - - - The group is now going to "move up the stack" and define metrics that pertain to general use cases (verticals). We have started to focus on supply chain and look to define basic performance and scalability measurements for that area. We reached out to the community a few weeks ago and received a lot of positive energy. Now we need to follow up. We also need to reach out specifically to project Grid and there are rumors of a Supply Chain SIG that we will also explore common areas with
      - STAC
      - Due to holidays , winter breaks, and vacation schedules, meetings have been less frequent but that will change now as we get into the doldrums of February. There was also a natural slowdown due to publishing our Metric Document. Overall the group has been active and there have been many discussions on what to do next. We decided on defining metrics metrics for supply chain.
      - The group has tried to "move up the stack" and define metrics that pertain to general use cases (verticals). We started to focus on supply chain and looked to define basic performance and scalability measurements for that area. However we got sidetracked with an exploration of working with STAC and shifted focus to some financial areas (my fault on leading us down there). That partnership and work never came to fruition. Now we are back to looking at Provenance and defining some terms and workloads for that area. I will be reaching out to project Grid and the new Supply Chain SIG to see what expertise they can add.
    - - Just some agenda item ideas for tomorrow's call (not in priority order):
      - 1) Deprecating the old Fabric adapter (hard to maintain, lot of related issues/fires to put out, only provides the extra tx-mode feature compared to the CCP adapter, and haven't seen active usage of it in the community) :star:
      - 2) Modularizing the core package (make the flow, monitor, client, reporting parts more object-oriented with clean APIs), a must-have for starting versioning
      - 3) Brainstorming about how a useful Caliper UI would look like (more importantly, what it should be able to do), this would facilitate the integration of the internship project that starts soon :star:
      - 4) Being more strict about github issues (misconfig should be forwarded here or to the mailing list, only real bugs and enhancements should be tracked through github issues)
      - 5) Cathcing up about what's everyone working on 🙂
      - 6) Other things you can think of
  - - - The latter was implemented from scratch to utilize the common connection profile (ccp) feature of the sdk. It has some extra features from a usability point of view.
- - - - Design
        
        Understanding the desires, needs, motivations, and contexts of people using products
        
        • Understanding business, technical, and domain opportunities, requirements, and constraints
        
        • Using this knowledge as a foundation for plans to create products whose form, content, and behavior are useful, usable, and desirable, as well as economically viable and technically feasible
      - Digital products have sloppy habits
        
        Furthermore, the appearance of software—especially business and technical applications—can be complex and confusing, making navigation and comprehension unnecessarily difficult.
      - Why digital products fail
        
        • Misplaced priorities on the part of both product management and development teams
        
        • Ignorance about real users of the product and what their baseline needs are for success
        
        • Conflicts of interest when development teams are charged with both designing and building the user experience
        
        • Lack of a design process that permits knowledge about user needs to be gathered, analyzed, and used to drive the development of the end experience
      - The mature software development process
        
        Initiate (Managers) ---[Mandate (Users)]---> Design (Designers) ---[Specs<->Feasibility/Feedbacks]---> Build (Developers) ---[Code <-> Bug-report]---> Test (QA) ---[Product <-> User-input]----> Ship
      - Understanding the data is not the same as knowing what your users love.
      - Just as we would never permit the prosecutor in a legal trial to also adjudicate the case, we should make sure that the people designing a product are not the same people building it.
        
        Thus, developers often are required to choose between ease of coding and ease of use.
      - Confusing domain knowledge with design knowledge.
        
        Customers, although they might be able to articulate the problems with an interaction, often cannot visualize the solutions to those problems.
        
        The patient can describe the symptoms, but it takes the doctor’s professional knowledge to make the correct diagnosis and prescribe the treatment.
      - A Successful Product is Desirable, Viable, and Buildable :star:
        
        Desirable (Designer)
        
        User model
        
        Motivation
        
        Behaviors
        
        Attitude and aptitudes
        
        Product design
        
        Design schedule
        
        Form and behavior spec
        
        User effectiveness and customer adoption
        
        Overall product success
        
        Viable (Management)
        
        Business Model
        
        funding model
        
        income / expense projections, etc.
        
        Business Plan
        
        marketing plan
        
        launch plan
        
        distribution plan
        
        Sustainable business
        
        Buildable (Technologists)
        
        Technology Model
        
        core technologies
        
        technology components
        
        build vs. buy
        
        Technology plan
        
        engineering schedule
        
        engineering spec
        
        Project delivery
      - :red_flag: Knowing the real user goals
        
        Most UI are ineffective
        
        • Make users feel stupid.
        
        Make users feel smart.
        
        • Cause users to make big mistakes.
        
        Prevent that!
        
        • Require too much effort to operate effectively.
        
        Make it simple.
        
        • Don’t provide an engaging or enjoyable experience.
        
        Make it fun!
        
        The said need is not the true needs
        
        True needs are mostly more personal
        
        when companies do focus on the users, they tend to pay too much attention to the tasks users engage in and not enough attention to their goals in performing those tasks.
        
        Difference between goal and activity tasks
        
        Since goals are driven by human motivations, they change very slowly—if at all—over time. Activities and tasks are much more transient, because they are based almost entirely on whatever technology is at hand.
        
        . Understanding users’ goals can help designers eliminate the tasks and activities that better technology renders unnecessary for humans to perform.
        
        A general guideline of interaction design :star:
        
        good design makes users more effective
        
        This guideline takes into account the universal human goal of not looking stupid, along with more particular goals of business throughput and ease of use that are relevant in most business situations.
        
        Build a of you products, including yourself, more efficient.
        
        Although it is the user’s job to focus on her tasks, the designer’s job is to look beyond the task to identify who the most important users are, and then to determine what their goals might be and why.
        
        This occurs because the user’s mental model of his tasks usually differs from the software’s implementation model.
        
        User interfaces should be based on user mental models rather than implementation models.
        
        In other words, design provides true product definition, based on user goals, business needs, and technology constraints.
        
        :red_flag: The goal-directed design process
        
        Research -> Modeling -> Requirements -> Framework -> Refinement -> Support
      - If we design and develop digital products in such a way that the people who use them can easily achieve their goals, they will be satisfied, effecive, and happy. They will gladly pay for our products—and recommend that others do the same. Assuming that we can do so in a cost-effective manner, this will translate into business success.
      - Core Questions For Goal-Directed Design :question:
        
        • Who are my users?
        
        • What are my users trying to accomplish?
        
        • How do my users think about what they’re trying to accomplish?
        
        • What kind of experiences do my users find appealing and rewarding?
        
        • How should my product behave?
        
        • What form should my product take?
        
        • How will users interact with my product?
        
        • How can my product’s functions be most effectively organized?
        
        • How will my product introduce itself to first-time users?
        
        • How can my product put an understandable, appealing, and controllable face on technology?
        
        • How can my product deal with problems that users encounter?
        
        • How will my product help infrequent and inexperienced users understand how to accomplish their goals?
        
        • How can my product provide sufficient depth and power for expert users?
- - - - The example benchmark configuration files are named like config-xxx.yaml and are located in the directories of the sample benchmarks. The configuration contains test round and monitoring settings. You can refer to the Architecture documentation for details.
    - - The blockchain configuration file is named like xxx-yyy.json/, where xxx is the blockchain type (for example, fabric, sawtooth, burrow or iroha), and yyy is some deployment-specific information, like the language of the chaincodes (for example, fabric-go.json for a Fabric deployment). You can refer to the platform-specific configuration pages for more information.