My involvement on this project was lead developer, as well as UX engineer.

The simplified workflow is shown below:

Behind the Scenes

As much as I like working on the front end of things, most of the development is in the backend. There are countless “Batch Jobs” that run on a schedule that ensures that each record follow specific guidelines. This includes if employees (both submitter and payee) are in good status. There are specific codes that trigger a warning – if one do not pass. Another check is making sure that the timeline aligns with specific pay sheets, as well as making sure the currency matches.

A separate process also makes sure that the manager is reminded for approval. The notification system is via email, so a check has to be done if the manager has taken action – or else, we bug them again. A whole separate process happens when an OTP gets rejected.

Once the record makes it to the end of the validation, it gets processed for payment. This means we have to created a file and store in a central location, for another software to pickup.

The Front End

This is the part that I enjoy building the most. The planning started with a series of wireframes. The wireframes are done in Figma, with iterations and approvals with the stakeholders. We use Jira to keep these conversations flowing.

A simplified version of the form entry is shown below:

The form is all JavaScript driven. It’s a single page application that talks to a couple of API endpoints. To support the form design, a master-detail relationship has to be done with the data. For each record, you can add multiple charge codes, as well as header approvals. So in total, three main tables are required.

The screenshot below shows the ability for users to add multiple charge codes per OTP.

We used a framework called LWC, which has a design system attached to it. And while a lot of components are available and ready to use, I ended up having to build a lot from scratch. Things like custom fields with ajax validations, file uploads, people pickers, modals etc.

The Landing Page

Set aside the form for a minute and let’s talk about the landing page. So many users create OTPs so much – that they need a landing page to see the status of their records. This basically becomes the “home” of the application, with their records showing in a list format.

From this page, they can filter records, do a search by name or record id. They can also launch a new payment from here.

Quick actions are also added such as “recall” and “delete” so users don’t have to bring up the record. They can simply do it from this page.

Pagination and tabbed views are also added for ease of use. The animation below shows a brief overview of what the application can do:

Summary View

For each OTP, each charge codes require a manager’s approval. This can be just a single person, but most if the time, its different managers. There’s a view of the form that all the fields are read only, with action buttons for each line item. This view is smart enough to know who the current viewer is, and for which line he/she has access to click.

Note that front and back end validation is in place for security. So even if the viewer is savvy enough to hack the view, the server side knows who the current user is – and extra checks are in place so the approvals can’t be overridden.

A simplified version of the wireframes is shown above. Also worth noting – that each view is mobile friendly and thoroughly tested with modern phones.

An actual screenshot of how the action buttons look, if the user has access to it.

A few more screenshots of how the application looks in a mobile device. Even though most of OTP’s users are using desktop, the full functionality is available in mobile. In addition, there are a few customizations that have been built to handle mobile users.

Overall, the project was a great success. Many users consider OTP a huge time-saver. It ultimately replaced quite a few legacy systems we used in the past. Many especially liked the UX and the details that went into the process.

Finally, below is a screenshot of the files and how many lines of code that makes up the application. As mentioned, most of the code is server side (Apex) and the rest is front end languages such as JavaScript, CSS and HTML.

The post One Time Payments appeared first on Michael Soriano.

My role for this project is Lead Developer. The project was done in React and WordPress.

The basic functionality is shown in this diagram:

Several rounds of wireframes and prototypes were done in Figma. A quick representation is shown below.

The public side of the application is a map. I used Leaflet for the map technology, along with Mapbox for the map styling. All interactions happen as layers on top of the map – either as modals or sliding sidebars. And since the application is wrapped inside our existing WordPress site, it had to use Bootstrap because it was already loaded on the page.

The company branding had to reflect in the map elements. This includes typography, icons, images, markers and backgrounds.

Plotting Locations

So for the markers on the map, I created a custom post type that can be entered in the admin area. For each record, I had to provide an easy way for the locations to pull up, as well as plot the coordinates automatically. A little help from Google Places API did the trick.

The users simply add an address and the API would come back with suggestions. The coordinates that is required for the marker placement is handled upon selecting a valid address.

Highlighting Parts of an Image

So as soon as a product marker is clicked, a side modal appears on the right side of the page. This includes more information about the product. In most cases, a hero image is presented along with marked sections highlighting key functionalities of the product.

This is done using CSS Positioning on the actual image. In the backend, users simply estimate the coordinates on where they want the pin to appear. This is done using input sliders.

All of this done using custom meta boxes, mainly using jQuery and HTML in the WordPress admin area.

Search and Filters

In addition to the map, there is also the ability to filter the pins. This allows the presenter, to only focus on a pre-defined set of projects.

The search mechanism is a simple text match query. The term looks inside the title, category and description – which sort of acts like a filter as well. There is an additional “Advanced Market filter” sidebar, which I thought was redundant. It’s also a set of filters, but instead of icons, checkboxes with labels are used.

Finally, although really designed for wider screens – I had to make it “semi” usable in mobile devices. The map responds to smaller screens pretty well. Although there’s not much we can do as far as presenting both the map and the overlays at the same time.

In the end, the sidebars and modals simply take up the entire screen, giving the user an option to close it.

Using a framework like React as well as JavaScript modules is pretty remarkable. This ultimately allows developers to build a fairly complicated application, with just a few lines of code.

Virtual world took approximately two weeks to build. The project was delivered to the owner, with just enough time for users to enter data and get trained on how to present the front end. Continuous improvements are still being implemented to this day.

The post Virtual World appeared first on Michael Soriano.

Yes – it was archaic.

The Hardware/Software Request system was created to replace this. My role was Lead Developer and UX engineer.

The diagram below describes how the system will work.

So we’re building a “Shopping Cart” system. Not a complicated one – just one that will work with our employees. So we didn’t need all the bells, nor the whistles of a full e-commerce site. The image below was taken from a series of wireframes done in Figma.

As you can see, the process is simple. Browse, add to cart and submit.

The Catalog

The design of the catalog is pretty straightforward. It will be two columns, with search and filters on the left, while the list of products in the main container.

I’ve also added small design elements such as a progress bar. This acts sort of like a “breadcrumb” – to let users become aware of the steps.

I’ve decided to bring the whole product dataset on load. This is against the regular pattern of grabbing small result sets at a time. But since I already know that there will never be a lot of products – I think it’s worth bringing the whole thing in.

The results are fast and snappy searches, filtering and paging.

Details of the each product is also shown in a modal once clicked. This product detail has a mini carousel that shows the product images.

The Shopping Cart

Once the user goes to view the cart, the search and filters disappear and the progress bar advances to the next step.  Directly below are the details necessary to complete the order. So its basically the shopping cart and checkout in one page.

Just like a regular cart, users can update/remove the items in the cart. The price automatically adjusts accordingly.

There is no payment or credit card information necessary. We utilize “charge codes“, so the department pays for the order. The shipping address is pre-filled with the users information, but they also have a chance to change it.

Once the form submits, it writes to the tables, as well as another API is called to process the order.

The screens above show how the software looks in a mobile phone. A lot of our users actually order through their phones.

Finally, the image below shows a quick summary of the files and lines of code that make up the application.

The project was a big success. So successful that we’ve added the ability to order software to it as well. Users are thrilled that they can now order hardware easily – a big improvement from the old system.

The post Hardware Request appeared first on Michael Soriano.

In a nutshell, a user can use this system to enter the risks involved in a project. They will have the ability to add taxonomies, notes as well as add a value to each risk.

Each risk is project based. Many risks can be assigned to a single project, although risk information can be shared between multiple projects. A custom taxonomy relationship had to be built to support this design. Additional functionality such as archiving, cloning, escalation and flags are all baked in to the system as well.

Creating / Updating Risks

One of the unique features of the application is the risk entry form. The form itself sits inside a modal – that appears right on top of the grid. This allows users fast and easy access to more details about the risk, as well as adjust the underlying data.

Below shows a simplified wireframe of the risk form + data row.

The animation below shows the part of the form with custom sliders. When the sliders are changed, the rating graphic gets updated. This unified graphic approach gives users a quick sense of how each risk should be evaluated.

Another unique feature of the application is a quick overview of the assessments that are in the system. A couple of chart options give the viewer a general scenario of how many assessments need action.

An advanced search form as well as filter options is also added for users find their assessments easily.

The Dashboard / Grid

One of the main features of ParRisk is the Grid. The grid basically shows a project – along with the corresponding elements that go with it. This includes the areas and categories that can be expanded and collapsed. Inline editing is enabled, so users do not have to jump from one modal to another, just to update information that is already present in the grid.

Tabbed navigation is added to give users a fast way to switch views. This includes access to project information, attachments and reporting.

The real meat of the grid are the risks. Each risk row shows the graphic I mentioned above (inherent and residual risks). The algorithm for determining this graphic is stored in custom metadata – so it can be adjusted easily, without having to update the source code.

In addition to the desktop view, it also has to be render good in mobile devices.

The application architecture is single page, with routes that determine records, forms as well as filters and search options. We use a library called “Aura”, which is template based JavaScript framework. The backend is stored in Salesforce, along with external modules such as ChartJS for the charts.

The project took a little over two months to build. Additions such as automated notifications, batch processing and scheduled jobs were implemented.

Overall, ParRisk was a huge success. It received a lot of recognition, along with many happy users using the tool on a daily basis.

The post ParRisk appeared first on Michael Soriano.

It is designed for information and collaboration. Alumni Portal was definitely a worthwhile website to build.

The site is complete with custom user registration, a commenting system, user profile and Workday news feed. The Alumni site has many components that makes it a pretty interesting site to visit.

ReactJS and WordPress API

We chose a very familiar backend – which is WordPress. This allows our users to add content and manage external users easily. WordPress also allows us to add functionality via plugins – which makes development a breeze. I had to write a custom API that imports our intranet news into WordPress automatically. This is so that users don’t even have to login to the site at all to keep the news fresh.

The Front End is using ReactJS.  This allows the site to load fast for good user experience. And with development build step, the site remains small and nimble. We stuck with Bootstrap for the CSS and Responsiveness of the pages. This was a familiar part for me. I’ve used Bootstrap for so long – that I can’t imagine building applications without it.

Single Page App

ReactJS makes the entire site a Single Page Application, interacting with the WordPress REST API, along with our custom ones written in NodeJS and PHP. Again, since everything is AJAX, the site is fast – which is good user experience.

The commenting system is open for all users to enter the site. When you enter a comment, it automatically adds it in the page – without a refresh. You can also edit your own comment inline. This means that you are not stuck with a bad comment – you have a chance to change it on the spot.

A user profile section is also available. This is a big React Form – fetching and posting data to the user API.

Workday and AWS Lambda

Lastly, the homepage features a “job scroller”. The aim is for former employees to see what jobs are available, and possibly even return for a position.

The feed for this section comes from our recruiting system called Workday. Workday has a functionality called RaaS  – which generates a report by the recruiting agents. These reports are then exposed via an API in XML format.

I used AWS Lambda and wrote a small NodeJS script to fetch this data. This is mainly the endpoint PHP is using to expose to the front end.

Overall, Alumni Portal had taught me many things especially with new technologies like ReactJS, AWS Lambda and NodeJS.  But most importantly, it had taught me a lot about our company. The culture, people and development practices.

Note that this was already a rebuild – from the previous version that I also wrote – using BackboneJS and Sharepoint. The site launched is set to launch September 2019.

The post Alumni Portal appeared first on Michael Soriano.

It is simple, elegant and sleek. But most of all, I tried to make it as user friendly as possible. Plenty of times I find myself browsing and just enjoying what NASA has in their archive.
View Live Site

I have set pre-built searches in the sidebar – not just for fast searching, but also so that I could use the “rockets”, “moon”, “earth” and “space shuttles” icons. I simply thought they look good.

Also in the sidebar, is an area reserved for the Filters. As soon as you search, the filters get filled up by the meta data of the search, namely: “By Center”, “By Photographer” and “By Keywords”.

Clicking on these filter links will refine your search results.

The site was built using NodeJS for the back-end proxy, and VueJS for the the front-end framework. I also used Axios for my HTTP calls for both front and back.

You will also notice that the page never reloads. This is because it’s a SPA (Single Page Application), with the benefit of speed and better user experience.

I don’t know if you’ve noticed, but the URL’s change – even though the page is technically never reloaded. This is called a page routing – which is made possible by VueRouter. So you can technically get to the search results, filtered results, single item detail – even by clicking back, forward or even refreshing the browser.

Also – you can send the said links via an email and it will still take you to the intended view.

The final thing you’ll notice is that the site is responsive. It’s intended to look good from a large desktop monitor – down to a small mobile device. I used Bootstrap framework to achieve this functionality.

I especially like the thumbnails on hover, where a subtle “zoom” is added. The sidebar also can be expanded and collapsed. Again, all of made possible with CSS and a bit of JavaScript.

So take NASA Images for a spin. Note that the site may take a bit of time on first load – this is because it’s sitting in a free account in Heroku and the “dynos” go to sleep with inactivity. And it takes a little bit of time to “wake up”.

The post NASA Images appeared first on Michael Soriano.

The jobs are housed in Taleo, so we had to write to their API to show and sprinkle the jobs all over the site. This was not an easy task, and had to involve not only programming, but the talent people as well. The jobs themselves had to be in categorized in a way for our parser to grab.

The design was done by our Creative Department, which established the Parsons brand very well.

As mentioned, this was our first open source project, so we’ve utilized technologies such as Git and Amazon’s CodeCommit for our repository, s3 for storage and CodeDeploy for deploying code to the servers.

The development workflow was a streamlined process. And I, being the lead developer – was very happy with the results.

The front facing pages are built on WordPress, so the theme had to translate to our designs. On top of that, the pages were to be updated by Talent themselves. So custom fields, post formats and post types had to be easy enough for them to use.

The WordPress side was running on Bootstrap – so the pages render in mobile devices.  The custom fonts are brought in by typekit, so they had to be meticulously coded to be legible – in phones, tables and so forth.

The images are optimized, yet had to be coded in a way that they are the right sizes – again for different devices.

The job listing and detail pages were still in Taleo – so we had to duplicate the header, footer and css for the site. This was not an easy task because the Taleo platform doesn’t allow JavaScript to be inserted, meaning – I had replicate the functionality by using only CSS.

Finally, the project was a huge success – and it gave open source a good name to our company. Which paved the way for many more projects like this in the future.

The post Careers at Parsons appeared first on Michael Soriano.

Simple and Clean

What I especially liked about the Vimi project was I got to design it. There are plenty of material online on creating app websites – which includes icons, phones and tablets. The Vimi people wanted the site simple and clean – so that’s what I intended on doing.

The screenshot above is a set of icons describing what the VimiChat application can do. This was featured right below the hero image in the homepage and was good match.

Keeping the Brand

Part of the challenge was to match the website with the actual Vimi app. The logo, typography as well as the colors – all were kept to provide that sense of brand. Below is an example of the application colors + icons – matching the colors and typography to the right.

Brand is important to the Vimi team, so I made sure the experience of the website was holistic and complements the brand.

WordPress Please.

The Vimi team specifically asked for WordPress because of it’s simplicity and ease of use. On top of that – WordPress powers about 25 percent of the world’s websites – so it’s easy to get support at time of need.

I have plenty of PHP and WordPress experience – so of course, I did this part as well.

The best thing about designing and coding – is I feel that I built that whole thing. From “soup to nuts” – Photoshop and my code editor was open together the entire time. Switching from design to code made things fast and enjoyable.

Below shows the ideal “sidebar” template for the internal pages. A “Search” form that still adheres to the color palette of the site.

Note the titles, links, headers and navigation also matched the company brand.

The Vimi folks also wanted to start their “blog”. This was not a problem with WordPress. As you may already know, WordPress IS a blog. Developers such as myself – just figured out ways to make it into a CMS. With the right skills – WordPress will do the job, and do it well.

Finally, the hero section above is for the homepage. Notice that the site is centered around the Vimi app – with call to actions to the downloads in Google or Mac store. In addition, the site is fully responsive. So the site is fully accessible in different resolutions – desktops, tablets and mobile devices.

The post VimiChat appeared first on Michael Soriano.

Our in-house designers had done a good job in the wire frames as well as the mock-ups. The pages were sleek, modern and most importantly – adhered to the client’s branding. It was then up to me to convert them into modular templates. It also had to be HTML5 and CSS3 compliant. And for the first time for the site owners, the application had to be usable in tablets and phones.

The challenge was, as the design kept evolving, the static HTML files wasn’t going to cut it. I had to think of something to streamline the process.

Static Page Generator

My solution was to build a static file generator. One that will allow me to “template-ize” the common files such as the header, navigation and footer.

I had built a local application, that is somewhat of a static file generator in PHP.  I had modeled it closely to how WordPress templates work.

The program was simple. I view and edit the files in PHP. And if all looks good, I load another file called “generate.php” that will look through all my files and create an HTML version of it. And since there were close to a hundred pages, I also had to zip the files, ready for delivery.

The output was an easy to maintain system regardless of the number of change. The templates can be re-used with any content, making it a true static file generator program.

The entire process took about a couple of months. I had learned a lot especially the inner workings of how our internal processes work. The programming however, is pretty basic – but I still had exercised what I know to produce something worthwhile.

Our client was extremely happy with the pages. I also was able to reuse my program with another similar project.

The post PennDOT Safety appeared first on Michael Soriano.

A Single Page Application

I chose the “Single Page Application” (SPA) approach since all of the code will be front end. It is an intranet, so no SEO value is required. Basically, the entire application is driven by JavaScript and CSS. In addition, an SPA Means that there will be no page refresh, no traditional “POST” form submissions. All transactions to the server is via AJAX – making the application fast and responsive. Ultimately just a better user experience overall.

Below demonstrates the entire life cycle of updating and creating a project:

Adding a project stays within the page, as well as filtering, sorting and paging are all done dynamically. A “quick update” feature is also available where users can update the project status and type inline. The design is mostly using our existing Brand-enforced CSS styles.

REST API Backend

This was one of my first exposure to SharePoint’s REST, so I had to learn as I build. SharePoint is Microsoft’s Content Management System as well as application framework where you can interact with users, content, workflows and it works seamlessly with existing programs.

I was able to built the basic SPA, which was using the basic CRUD utilities of the REST API. Also, all data was stored in SharePoint lists – which are utilities inside SharePoint where users can further interact with the data such as exporting to Excel and run reports.

Completing the application took approximately two months, with the help of plugins and libraries such as jQuery for DOM manipulation, Backbone.js for MVC code structure, Underscore.js for templating.

We didn’t use a generic library for form elements such as auto suggest and file uploaders. Instead, we implement our own and made them plugins. One of the most challenging input elements was the datepicker – which we used jQuery Date.

Finally, since our intranet is already running Bootstrap, the application looks good on a mobile device. This wasn’t in the original requirements, but the client was really happy that they can manage their data in their phones.

The Project Tracker App was one of my most favorite projects to build. I gained valuable knowledge with JavaScript, REST, Backbone.js and Underscore.js. Most of all, it was an application that I am truly proud of building.

The post Project Tracker appeared first on Michael Soriano.