In this last sprint my team and I ran into a few complications. We were trying to figure out how to go about creating these components that we are supposed. The class as a whole decided the best route to take was to break the amrs app down even more on GitHub so that each group would have their own component and there would be a ‘master’ branch so in the end we could push and merge everything onto that.

Some difficulties we had to work around included having to know what the layout would utilized because everything was sent over Zeplin but created off another platform (maybe adobe). We definitely are on the right path moving forward for the next sprint.

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

Hello, again my dear fellow readers!

In this blog post, I will be reflecting on the events of these past two weeks or the third sprint and I have some good news to share will all of you; things are happening!

Over the past couple of sprints, or four weeks in real time, things were slow and consisted primarily of simple set up tasks, npm errors, and learning about testing frameworks. At last, we have received communications from our AMPATH representative and we have been given both direction and a task.

The new direction we are headed in is admittedly different than where we thought we would go but that is just fine by me. We will be working with the other AMPATH groups to collectively make a mobile app version of the AMPATH software. From our AMPATH representative, we received a group of 6 different videos. Each detailed a part of the app that he wanted to create and gave an overview of the idea for what they would look and operate like. It was decided that, due to a large number of groups working on the AMPATH project this semester, the work would be divided up into individual screen components. This resulted in our group picking the sidebar or the “burger bar” as the AMPATH representative so colorfully put it (I have honestly never heard that term before). The representative had helpfully set up a Zepplin board with mock-ups of each element that he had portrayed in the videos. However, no one was able to view them due to Zepplin policies. This issue was resolved however it did take a couple of days as the AMPATH representative had to invite each of us one by one. Once, we were in, each of us was able to get a good idea of what was wanted.

This has led our group onto the next step, to learn Angular for mobile development! Now Angular for web page design I have done. Although it was only one semester, it was still experience and thankfully it helped create a base I could jump off of when searching for mobile Angular tutorials. One of our group members found two excellent websites to help visualize and learn mobile Angular. The first was a very helpful demo website called Mobile Angular UI. It is a demo site that aims to demo every aspect of what mobile Angular can do such as scrolling, tabs, touch, swipe, and most importantly, sidebars. While this aspect is not immediately available, all it takes is resizing your browser to see it in action. The useful tutorials and information for how to actually implement sidebars came again from Mobile Angular UI.

From there, our group ended the sprint, discussing how the sidebar would work on each individual page and where it would have to pull the necessary info from to operate properly. Since we just started this part, it will regrettably have to go into my next sprint retrospective. For now, this sprint has left me with more knowledge on overall Angular programming as it is going mobile!

That’s all for now readers. See you at the end of the next sprint!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

It’s time for Sprint-3 Retrospective Blog Post. As you are probably aware by now during this semester I will be working on a AMPATH project with a team for my Software Development Capstone course . As part of our assignment we are assigned to complete a Sprint Retrospective blog post at the end of each sprint. As of Today, March 26th, 2019, we have completed Sprint-3. During this third sprint we were able to get everything we intended to get done during this third sprint cycle.  For sprint-3 everyone in the team had the same yet individual kind of task. These task were:

1. As a developer working on ng2-arms I need to watch the provided YouTube tutorials on the #ampathofficial Slack channel, to get a better idea about what kind of web app we’re building.
2. As a team of developer working on ng2-amrs we need to decide as a team, which part of the ampath mobile project suggested in the tutorial we will be working on.

During this sprint we was able to complete all the task we set, plus a few extra small side task. A few of the side things were to read about  unit testing – mocking for angular testing and read Mobile Angular Docs. The YouTube video talked about few of the simple type of application that can be done to try to make a simple application to deliver healthcare using a more user-friendly application. The video mention a few things each team can work on in order to contribute to this new goal. After discussing with the team about the video and what we are interested in working on. As a team we decided to work on “the left navigation bar”. For the next sprint I believe we will be focusing our time on the what, who’s, and how we going to focus and ensure that are left navigational bar will work.

During sprint-3, I’ve learned a little about mobile angular doc, and a little more about what direction and how I will be contributing to the ampath project. While reading about mobile angular I discovered the different type of possibilities that can be done working with angular. See, with angular we can work on creating androids or OS application. Which I found pretty interested and will be doing further research on it. Another thing is, watching the video provided by one of the official ampath person help me understand and kinda get a mental picture of where this project is heading and what will be expected from my team and I. During this sprint I also, learned that we will be using mocking for our testing instead of going in and using real patients data. In light of everything I learnt there is nothing very special that went on that requires details explanations or strategies that would required for handling things different next time. That being said by the looks of things this project is going to be fun and interesting. I truly hope this project goes without a hitch, without me making things more complicated than it has to be.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

As I mentioned in my Sprint 2 Retrospective, this sprint was going to be significantly more exciting than the last sprint. This absolutely proved to be correct, because our team now has a project and a component of the project to work on! This is a very exciting development, because now we can finally start coding! We have been in touch with a representative from the AMPATH team, who has been giving us further information and wireframes/designs. Our final project will eventually start to reproduce these designs, and the remaining sprints will document the progress on that code.

But before that, we have been receiving lots of information about the type of work that we will be doing for the rest of the semester. Our project is the completion of a mobile app that simplifies the AMPATH point-of-care system, which is currently only present in a desktop interface. This app ideally will contain various components, which include: a search bar to find patients with an accompanying results page, a form that would appear when retrieving specific patient information, multiple lists of patients which can be toggled with a side navigation bar, a selection of different form types when choosing a patient to learn more about, a form with multiple tabs that contain different but related information, and a bottom navigation bar for further options. All of these parts of the mobile app were designed by the AMPATH team, and we were able to observe the wireframes of each component on Zeplin, a website which joins the roles of designers and developers. We are also not going to be provided a server, so we also have a team composed of members from different groups starting to work on mocking a back-end server (releasing pre-defined data rather than live data) so that the app can mimic retrieval of real-time information. In order to do this, the team is determining which of the front-end components will require some sort of back-end communication, so that the server can be mocked properly and fully.

Over the course of this sprint, we have mainly been setting up our coding environment with the new knowledge of what our project is going to be, as well as the part of the project that each team will be working on. Every team from Worcester State who is working on the AMPATH project has been connecting to a GitHub repository which only has a blank Angular project and a README/License. From this point, progress on each component of the app will be part of a separate branch in the GitHub project. We have been deciding how to go about diverging so that each part of the work is separate from every other component. Some ideas included individual or team forking, as well as team branches. However, due to possible changes in teams, as well as members of different teams working together, the decision is to work on component or feature branches.

I am very excited to see what kind of development process we will make over the course of the next sprint! Thanks for reading!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Sprint three lasted a week longer than the other sprints due to spring break, resulting in a lot more work getting done compared to other sprints. Starting on March 6 until March 26, in our sprint backlog we planned on covering some posted videos and coming up with things to do as we went along.

The videos were posted in a slack channel by the owner of the AMPATH project, Gregory Schmidt. Greg commentated a walk through of what the app should look like, helping us get familiar with the various stages of the user interface. This also helped us understand what was being done on the backend when searching for patients or clicking on a patient profile. Greg also posted a shell of the project using a site called zeplin, which we all signed up for to view gregs content.

Once our research was done, we decided to clean up the backlog process a bit by moving everything we had on trello to a github project. The layout of both sites is similar and easy to transition to, we just copied and pasted the relevant planning information. Each team in the class picked a certain feature of the app to work on, we chose to tackle the navbar functions.

Since each member watched the youtube videos, we added a few things to our ongoing tasks while we moved them to github. Since our project is a mobile angular program, we found a link (provided below) with a lot of useful information. The site includes examples of how to get started on our navbar, we added that task to our planning board and aim to make a lot of progress towards a built prototype during the next sprint.

http://mobileangularui.com/docs/

In our last meeting, our group brainstormed some ideas of what our navbar would look like, what it will do, and who will be using it. Currently we only have a few sketches, but it seems like we’ve decided for sure that we are going to include a home button and a sign in button. We discussed each group member working on at least one button, therefore we would have 5-10 buttons and the work is evenly distributed. One concern of mine is thinking of that many buttons to develop, the project seems not complicated enough to warrant that much work.

The home button is a simple starting point, it simply takes the user to the upper most page. The sign in button idea is still a work in progress, but hypothetically it should prompt the user for some information and filter a list with data pertaining to that user. In the hands of doctors or clinicians, this would display patients names with an appointment date and the condition of the patient.

Further ideas revolve around the concept of filtering down a patient list based on specified parameters, however this idea is still foggy and might not come to fruition. The same function could be done by searching for a patients name in the search bar, a component taken by another team. We still have time though, and we are fairly ahead of schedule considering the remaining work load of the project. By the end of the semester, the 15th of may, we should have a working navbar with multiple useful buttons on it.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

This sprint definitely was more productive than the last one, for the main reason that the scope and implementation of our project is beginning to take shape, and we are gaining more clarity about what we have to do to achieve our goals. At the end of the last sprint, everyone on our team decided that the component that we would be building would be the tab system for adding, modifying, and displaying information about patient records for multiple patients.

Early on in the sprint, Sam found some solid resources that angular provides with multiple variations of tab structures to choose from, and the skeleton codes were provided too. We took a little bit to decide which kind of style, animations, layout and otherwise we wanted to go with, taking into consideration that the everyday users for the project will be medical professionals who have to constantly have multiple tabs open and switching around. We didn’t want our component to feel cumbersome, we definitely value having a sleek easy to read style, and fast animations to streamline their workflow as much as possible. This design goal led us into ruling out certain features that would take a long time for animations or had unnecessary clutter.

After getting a consensus on our group’s design philosophy, seeing what tools angular had to offer us, and deciding on a general schema for our tab component, we discussed in class the need to use Ampath’s included services to make our project compatible with Ampath and useful in an electronic medical records system. Thankfully Andrew found all of that information in their core repository, which saved us a ton of investigative work. So what we have to do now is search through each of the services and their specification mocks to find which ones are relevant to our component and then we can begin creating our prototype.

At this point in our development, we have started to plan for creating a wireframe program which applies both the design we want, as well as the services we need to provide that contains the information and formatting that is relevant to the Ampath vision. Beginning the next sprint we all believe we should be ready to start coding and getting some demonstrable progress under our belts. We will have created a file with our skeleton code and we are hoping to push it to our local repository as soon as we can.

I am very pleased about the progress and mode of work with our group. We all seem to reach a consensus about what direction to go in quickly and effortlessly. We are all finding small ways to help further the progress of our team in our own ways, and at some point during the sprint each member of our group was able to contribute something helpful to all of us. We are all understanding and willing to divide and tackle any particular work tasks we need to get done. I definitely wouldn’t change anything about our group dynamics and I am satisfied that we are successful.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.