Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Full UI integration -> Build planning #502

Open
MLanghof opened this issue Jan 9, 2018 · 2 comments
Open

Full UI integration -> Build planning #502

MLanghof opened this issue Jan 9, 2018 · 2 comments

Comments

@MLanghof
Copy link
Collaborator

MLanghof commented Jan 9, 2018

This pertains to point 4 of @brather1ng's roadmap (#463), but I think it needs to have larger scope. Tagging @l0g0sys and @EmmittJ for good measure.

If I'm not mistaken, we are looking to move from being a pure "passive tree planner" to becoming a complete "build planner", even if the current scope is just "computation rewrite". In this light, I believe we need to start thinking about the UI/UX concept for this whole thing. What we have right now is adequate for tree planning, but it would be a shame if the build planning was just tacked on.

Essentially, the question is how we want the build planning workflow to look like, and whether what we have right now is appropriate for that. But regardless of whether we do a large UI revamp, fit the build planning into its own space or squeeze it in between existing stuff, there is significant user interface work ahead. I'm no UI/UX guy (I assume none of us are), so these are the options I see, in order from worst to best:

  • We "wing it" and do whatever seems intuitive at the time. I fear this will be suboptimal, to say the least.

  • We more or less copy what Path of Building does. It works in the grand scheme of things, but stealing from them is not cool and there are probably things we can do better (or have to do differently, see GA).

  • We discuss (and probably also ask others, first and foremost the end users, about) different iterations for the UI and workflow (possibly ranging from sketches to function-less prototypes). Will involve significant work but should pay off greatly.

  • We involve someone who does this more professionally than we do. There's likely to be someone in the community who would like to and has the skills to help, but we need to reach out in that case. Would probably also involve the previous point.

First of all, am I correct with my assumption of going in the build planner direction, or would you rather keep the program's focus on pure tree planning? What is your/our long term vision of how people use the program, and what's the best way to get there?

Secondly, which option would you deem appropriate for coming up with the upcoming UI work (no pun intended)?

@brather1ng
Copy link
Member

I'm no UI/UX guy (I assume none of us are)

I'm definitely not one. I probably know the most about WPF from of us, but that's about it.

First of all, am I correct with my assumption of going in the build planner direction, or would you rather keep the program's focus on pure tree planning? What is your/our long term vision of how people use the program, and what's the best way to get there?

For me, going full build planner is where I see us going.

With a new computation system and related UI changes, I think we will be pretty much there. There are already a lot of build planning related things that make more (e.g. the saved builds system) or less (e.g. the equipment tab, the socketed gem feature) sense with the current tree planning focus.

Secondly, which option would you deem appropriate for coming up with the upcoming UI work (no pun intended)?

While getting a professional UI/UX dev would be the optimal solution, I'm less optimistic about that than you. Also, redesigning the UI as a whole would require rewriting or at last major refactoring of a lot of code in MainWindow and SkillTree. We should do that (cleaning MainWindow and SkillTree) at some point anyway, but it increases the scope of the shorter term goal by a lot. (great things to include with this would be a modular UI layout, think Visual Studio where you can rearrange all modules, and tabs for builds so you can have multiple open at the same time)

For the most part, I think we can work with a mix of the other three options depending on the part that needs to be worked on. E.g. the equipment tab doesn't need many changes that can probably made without much design work, while the current "Attributes" and "Character Sheet" expanders will need to be completely redesigned.

So yeah, it depends a lot on whether we can get someone on board that would do the majority of the UI work or not. If we can get one, we can go with option 3 and 4 and increase the scope of "Full UI integration" to more major design reworks. If not, it would make more sense to keep the scope on integrating the computation things for now. I personally don't really know how we would even go about including users in the design process, at least if that should go beyond asking for feedback on sketches/prototypes.

@brather1ng
Copy link
Member

I think a good solution here would be to develop an initial version, which would be limited to feedback on GitHub and our Discord. With that version, we can gather more feedback from other channels. We should also be ready for 3.0 Beta around that time, which I feel would be a great point to announce this whole rework more prominently (so not releasing at the same time as PoE itself).

@brather1ng brather1ng added this to the 3.0.0-beta.1 milestone Dec 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants