You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The documentation for WireMock is quite robust. This has the positive outcome of almost every case you could think of being documented. But the negative outcome is that users who are new to WireMock may not know which page to go to in order to get a code example. While standardizing documentation could lead to an increase in discoverability, another path that could be taken to increase user adoption would be learning paths.
What's a learning path?
A learning path would be something like a small tutorial that allows users to easily set up their own WireMock and play around with a sandbox to discover how they can implement certain solutions. Ideally, there would be three requirements for a learning path
WireMock code (either JSON or Java, but having both would be a plus :D )
Postman collection (or some other grouping of network calls for ease of use)
Documentation! To guide the user through their learning path.
What does the learning path accomplish?
Ideally, the learning path would allow users, especially those who are more hands-on learners, to engage with WireMock while attempting to solve a problem or discover how to use a tool. Additionally, when answering questions on StackOverflow, GitHub, or the Slack community, learning paths could provide another avenue to explain how to solve problems.
From my own personal experience, using a small sandbox I made to figure out the difference between url, urlPath, urlPattern, and urlPathPattern spurred me on my way to really using WireMock.
Why could this be unsuccessful?
Honestly, it'd be a huge endeavor. Even trying to slice the learning paths into fairly large groups would still require a ton of coordination and preparation before getting into actually creating the paths. What goes into one path vs. another? How prescriptive are the instructions? How are certain features documented/not documented?
Reference any relevant documentation, other materials or issues/pull requests that can be used for inspiration.
No response
The text was updated successfully, but these errors were encountered:
I think it would be a great improvement. Indeed it would be difficult to implement that with the existing documentation framework. I created #24 to move to Hugo or Docusaurus, and then we could start major rework.
W.r.t Learning paths, I would suggest starting from Quckstarts for the tech stacks we support at the momment:
Proposal
The documentation for WireMock is quite robust. This has the positive outcome of almost every case you could think of being documented. But the negative outcome is that users who are new to WireMock may not know which page to go to in order to get a code example. While standardizing documentation could lead to an increase in discoverability, another path that could be taken to increase user adoption would be learning paths.
What's a learning path?
A learning path would be something like a small tutorial that allows users to easily set up their own WireMock and play around with a sandbox to discover how they can implement certain solutions. Ideally, there would be three requirements for a learning path
What does the learning path accomplish?
Ideally, the learning path would allow users, especially those who are more hands-on learners, to engage with WireMock while attempting to solve a problem or discover how to use a tool. Additionally, when answering questions on StackOverflow, GitHub, or the Slack community, learning paths could provide another avenue to explain how to solve problems.
From my own personal experience, using a small sandbox I made to figure out the difference between
url
,urlPath
,urlPattern
, andurlPathPattern
spurred me on my way to really using WireMock.Why could this be unsuccessful?
Honestly, it'd be a huge endeavor. Even trying to slice the learning paths into fairly large groups would still require a ton of coordination and preparation before getting into actually creating the paths. What goes into one path vs. another? How prescriptive are the instructions? How are certain features documented/not documented?
Reference any relevant documentation, other materials or issues/pull requests that can be used for inspiration.
No response
The text was updated successfully, but these errors were encountered: